[pokeruby - pokeemerald] (GDB y VS Code) Usando el debugger

[Kaiser de Emperana]

Bueno más que un tuto este tema es un "chicos, esto existe". Voy a mostrar como usar usar mGBA y gdb en conjunto para depurar. No voy a explicar los comandos de gdb, asumo que cualquiera que esté leyendo este tema tiene cierta noción de programación y de como usar google.

Requerimientos:
- gdb para la arquitectura arm. (viene junto con el devkitARM, así que todos lo tienen)
- mGBA
- Visual Studio Code (opcional)

Pasos:

Spoiler: Ver que tengan pokeemerald actualizado

Abran el Makefile y miren si encuentan esto:

ifeq ($(DINFO),1)
override CFLAGS += -g
endif

Si lo tienen bien. Sino, tendrán que resolver los conflictos que tenga su proyecto y hacer merge con el el repo de pret.

Spoiler: Compilar pokeemerald/pokeruby

Para poder usar el debugger, hay que compilar el juego con symbolos de debug, por lo que si lo compilaron alguna vez antes de esto, tendrán que hacer:

make clean

Luego deben compilar el juego con:

make DINFO=1

Spoiler: Abrir el juego y crear un server gdb

Ahora abran pokeemerald.gba/pokeruby.gba con mGBA y dirijanse a: Tools > Start GDB server. Les va a aparecer esta ventana:

En local port pongan el número que quieran, yo elegí 2345, y a bind address lo dejan en "0.0.0.0". Luego clickean start y el juego se va a pausar.

Ahora toca elegir un camino:

Spoiler: Camino A: debugger por línea de comandos

Spoiler: Abrir gdb

Gdb es un debugger por línea de comandos. Los que tengan los binarios de devkitarm en path, podrán ejecutarlo tal que "arm-none-eabi-gdb". Los que no supongo que tendrán que agregarlo o usar "$DEVKITARM/bin/arm-none-eabi-gdb", yo haría lo primero...

Para abrir gdb con los symbolos del código fuente deberán ejecutarla tal que:

arm-none-eabi-gdb pokeemerald.elf

(O pokeruby.elf)

Spoiler: Conectarse al server

Desde gdb ejecutan:

target remote 0.0.0.0:2345

Donde 2345 es el puerto que hayan elegido en mGBA.

Spoiler: Y ya está...

Ahora hacen lo que tengan ganas de hacer:

Spoiler: Camino B: debugger con interfaz gráfica (Visual Studio Code)

Spoiler: Abrir el proyecto e instalar la extensión del debugger

Ahora simplemente abrimos Visual Studio Code y desde el mismo entramos a la carpeta de nuestro proyecto. Después entramos a la pestaña de extensiones e instalamos la extensión "Native Debug" de WebFreak.

Spoiler: Crear el archivo launch.json

Una vez instalada nos vamos a la pestaña de "Debug and Run" de VS Code y creamos nuestro archivo "launch.json".


(Seleccionando la opción GDB)


Y con los siguientes contenidos

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "mGBA",
            "type": "gdb",
            "request": "attach",
            "cwd": "${workspaceRoot}",
            "valuesFormatting": "parseText",
            "executable": "./pokeemerald.elf",
            "target": "127.0.0.1:2345",
            "remote": true,
            "gdbpath": "arm-none-eabi-gdb"
        }
    ]
}

Colocando el puerto correspondiente en target (donde iniciaron el server, en este ejemplo 2345).

En caso de que usen pokeruby, obviamente deberían cambiar pokeemerald.elf por pokeruby.elf.

Y en caso de que no tengan los binarios en de DevkitARM en PATH, deberían escribir la ruta completa de arm-none-eabi-gdb.

Spoiler: Y ya está...

Clickeamos ese hermoso botón de Play:


Y hacemos lo que tengamos ganas de hacer:

Spoiler: El debugger no reconoce los breakpoints

Si por alguna razón el debugger no reconoce los breakpoints que seleccionamos. Probar si se soluciona presionando el boton de Restart:

Y bueno... Saludos.

 

[KleinStudio]

Respuesta: Usando el debugger

Sabía que esto se podía hacer con mGBA pero todavía no me había puesto a probarlo.
Una de las cosas que más pereza me daba a la hora de programar en los proyectos de decompilación era que no tenía forma de debuggear lo que estaba haciendo y a veces hay cosas que se pasan por alto.

Tengo que probarlo cuando vuelva a tener algo de tiempo para este tipo de proyectos, supongo que se podrá vincular al GDB de VS Code así que me facilitará muchísimo el trabajar con esta plataforma :lovelon:

 

[Kaiser de Emperana]

Actualizo el post principal con la posibilidad de usar el debugger gráfico de Visual Studio Code.

 

[Samu]

Re: Respuesta: (GDB y VS Code) Usando el debugger

Actualizo el post principal con la posibilidad de usar el debugger gráfico de Visual Studio Code.

Te quiero.

 

[Kaktus]

Bueno más que un tuto este tema es un "chicos, esto existe". Voy a mostrar como usar usar mGBA y gdb en conjunto para depurar. No voy a explicar los comandos de gdb, asumo que cualquiera que esté leyendo este tema tiene cierta noción de programación y de como usar google.

Requerimientos:
- gdb para la arquitectura arm. (viene junto con el devkitARM, así que todos lo tienen)
- mGBA
- Visual Studio Code (opcional)

Pasos:

Spoiler: Ver que tengan pokeemerald actualizado

Abran el Makefile y miren si encuentan esto:

ifeq ($(DINFO),1)
override CFLAGS += -g
endif

Si lo tienen bien. Sino, tendrán que resolver los conflictos que tenga su proyecto y hacer merge con el el repo de pret.

Spoiler: Compilar pokeemerald/pokeruby

Para poder usar el debugger, hay que compilar el juego con symbolos de debug, por lo que si lo compilaron alguna vez antes de esto, tendrán que hacer:

make clean

Luego deben compilar el juego con:

make DINFO=1

Spoiler: Abrir el juego y crear un server gdb

Ahora abran pokeemerald.gba/pokeruby.gba con mGBA y dirijanse a: Tools > Start GDB server. Les va a aparecer esta ventana:

En local port pongan el número que quieran, yo elegí 2345, y a bind address lo dejan en "0.0.0.0". Luego clickean start y el juego se va a pausar.

Ahora toca elegir un camino:

Spoiler: Camino A: debugger por línea de comandos

Spoiler: Abrir gdb

Gdb es un debugger por línea de comandos. Los que tengan los binarios de devkitarm en path, podrán ejecutarlo tal que "arm-none-eabi-gdb". Los que no supongo que tendrán que agregarlo o usar "$DEVKITARM/bin/arm-none-eabi-gdb", yo haría lo primero...

Para abrir gdb con los symbolos del código fuente deberán ejecutarla tal que:

arm-none-eabi-gdb pokeemerald.elf

(O pokeruby.elf)

Spoiler: Conectarse al server

Desde gdb ejecutan:

target remote 0.0.0.0:2345

Donde 2345 es el puerto que hayan elegido en mGBA.

Spoiler: Y ya está...

Ahora hacen lo que tengan ganas de hacer:

Spoiler: Camino B: debugger con interfaz gráfica (Visual Studio Code)

Spoiler: Abrir el proyecto e instalar la extensión del debugger

Ahora simplemente abrimos Visual Studio Code y desde el mismo entramos a la carpeta de nuestro proyecto. Después entramos a la pestaña de extensiones e instalamos la extensión "Native Debug" de WebFreak.

Spoiler: Crear el archivo launch.json

Una vez instalada nos vamos a la pestaña de "Debug and Run" de VS Code y creamos nuestro archivo "launch.json".


(Seleccionando la opción GDB)


Y con los siguientes contenidos

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "mGBA",
            "type": "gdb",
            "request": "attach",
            "cwd": "${workspaceRoot}",
            "valuesFormatting": "parseText",
            "executable": "./pokeemerald.elf",
            "target": "127.0.0.1:2345",
            "remote": true,
            "gdbpath": "arm-none-eabi-gdb"
        }
    ]
}

Colocando el puerto correspondiente en target (donde iniciaron el server, en este ejemplo 2345).

En caso de que usen pokeruby, obviamente deberían cambiar pokeemerald.elf por pokeruby.elf.

Y en caso de que no tengan los binarios en de DevkitARM en PATH, deberían escribir la ruta completa de arm-none-eabi-gdb.

Spoiler: Y ya está...

Clickeamos ese hermoso botón de Play:


Y hacemos lo que tengamos ganas de hacer:

Spoiler: El debugger no reconoce los breakpoints

Si por alguna razón el debugger no reconoce los breakpoints que seleccionamos. Probar si se soluciona presionando el boton de Restart:

Y bueno... Saludos.

No sé que tan activo estés como para ayudarnos con esto, pero tanto @Samu como yo hemos intentado poner a punto este debugger desde el método aceptado por pret para el decomp, que es mediante WSL. Al usar WSL con gdb, hace el amago de querer funcionar, y de hecho hace la conexión, pero acaba tirando warnings y cierra la conexión.

Con eso casi casi se podría decir que si he logrado abrirlo en el VSCode, pero claro, las warning me putean y no puedo hacer un debug real, pues desconozco de donde puedan venir dichos errores.

Luego he probado haciendo uso de tu método, mediante la consola de cygwin y la terminal, y con ambas me reconoce el paquete y todo, pero a la hora de realizar la conexión...

No sé que pueda estar fallando en estas terminales, porque además me falla en las dos, sin embargo, desde WSL al menos la conexión si que la realiza.

No te puedes imaginar la falta que nos hace este debugger. Nos tiramos muchísimo tiempo para sacar fallos algo más complejos, si pudieras actualizar el post con un nuevo método para WSL estaría 10/10, aún así, si tampoco fueras capaz de conseguirlo, con dejar un fix para tu versión me serviría.

¡¡Un saludo!!

 

[kakarotto]

He usado windows 7 y funciona perfectamente con cygwin. Ahora uso windows 10 con WSL gracias a tu tuto y a mi no me tira los warnings esos y puedo depurar perfectamente. Si que es cierto que a veces funciona un poco raro y cuando termina los breakpoints no puedes cambiarlos en tiempo de ejecución porque se va al garete. Entonces sinceramente, parece ser un caso que ocurre esporádicamente. Yo lo hice funcionar instalando el paquete gdb-server, pero bueno, quizas no tengas mucho en cuenta este comentario.

 

[Kaktus]

He usado windows 7 y funciona perfectamente con cygwin. Ahora uso windows 10 con WSL gracias a tu tuto y a mi no me tira los warnings esos y puedo depurar perfectamente. Si que es cierto que a veces funciona un poco raro y cuando termina los breakpoints no puedes cambiarlos en tiempo de ejecución porque se va al garete. Entonces sinceramente, parece ser un caso que ocurre esporádicamente. Yo lo hice funcionar instalando el paquete gdb-server, pero bueno, quizas no tengas mucho en cuenta este comentario.

Ah, yo instalé el gdb a secas creo, quizás sea por eso. ¿Podrías pasar tu launch.json y en caso de tener, tu tasks.json?

 

[Kaiser de Emperana]

No sé que tan activo estés como para ayudarnos con esto, pero tanto @Samu como yo hemos intentado poner a punto este debugger desde el método aceptado por pret para el decomp, que es mediante WSL. Al usar WSL con gdb, hace el amago de querer funcionar, y de hecho hace la conexión, pero acaba tirando warnings y cierra la conexión.

Ver el archivo adjunto 5184

Con eso casi casi se podría decir que si he logrado abrirlo en el VSCode, pero claro, las warning me putean y no puedo hacer un debug real, pues desconozco de donde puedan venir dichos errores.

Luego he probado haciendo uso de tu método, mediante la consola de cygwin y la terminal, y con ambas me reconoce el paquete y todo, pero a la hora de realizar la conexión...

Ver el archivo adjunto 5185

No sé que pueda estar fallando en estas terminales, porque además me falla en las dos, sin embargo, desde WSL al menos la conexión si que la realiza.

No te puedes imaginar la falta que nos hace este debugger. Nos tiramos muchísimo tiempo para sacar fallos algo más complejos, si pudieras actualizar el post con un nuevo método para WSL estaría 10/10, aún así, si tampoco fueras capaz de conseguirlo, con dejar un fix para tu versión me serviría.

¡¡Un saludo!!

No uso Windows, así que no tengo para ponerme a probar con WSL.

Pero 99% seguro, sin haber probado nada, les digo que el problema (o al menos uno de los problemas) es que están intentando conectarse a la IP 0.0.0.0, que hace referencia a la propia computadora. WSL funciona adentro de una máquina virtual, así que en ese contexto 0.0.0.0 no haría referencia al host con windows. Y parece que WSL directamente no puede ni resolver 0.0.0.0 como si mismo, por alguna razón... Pero eso no importa.

Tendrían que bindear el server de mGBA a la IP de la máquina de Windows que corresponda a su red local, 192.168.X.X o lo que sea.

Creo que en windows pueden ver su IP ejecutando el comando "ipconfig" desde el cmd.

Y bueno, no se si habrá que configurar algo para que la WSL pueda acceder a la red local. Pero vayan probando con eso.