Todos somos humanos, y por eso erramos una y otra vez. Por suerte, en Dreamcast hay herramientas que nos ayudan a encontrar nuestros fallos. A continuación se muestra una herramienta muy fácil de usar, para luego pasar "al cañón de verdad", que es ni más ni menos la
compilación de un Debugger.
sh-elf-addr2line.exe
¿Añoras esos lenguajes que te dicen en qué línea petó el código? Te comprendo, que C/C++ te diga "Segmentation Fault" es una jodienda jeje.
addr2line, como su nombre indica, traduce una dirección a la línea de código. Veamos cómo funciona:
Primero, necesitas tener el fichero .ELF, y que tu .ELF haya sido compilado con opciones de debug (-g). Por defecto en KOS ya se compila con -g.
Un ejemplo:
Unhandled exception: PC 8c01016a, code 1, evt 00e0
R0-R7: 0000011a 8c5285c0 00000000 00000010 0000011a fffffffc 00000001 00000130
R8-R15: 8c161044 00000d00 0000011a 8c0c7780 8c0d5dd8 8c0c7260 8c16102c 8cffff90
SR 40000000 PR 8c010fec
kernel panic: unhandled IRQ/Exception
arch: aborting the system
A nosotros nos interesa el PC (Program Counter), ya que indica la línea en que se terminó la ejecución. Ahora, escribe:
>> addr2line -e hola.elf 8c01016a
Y nos devuelve (es inventado):
/usr/local/home/linux/dreamcast/kos/examples/dreamcast/basic/asserthnd/asserthnd.c:46
Fantástico no? :D
Si, por casualidad, hemos activado los FRAME POINTERS, tendremos más información extra:
-------- Stack Trace (innermost first) ---------
8c01016a
8c0101e0
8c010478
8c010062
-------------- End Stack Trace -----------------
Y si ejecutamos:
>> addr2line -e hola.elf 8c01016a 8c0101e0 8c010478
/usr/local/home/linux/dreamcast/kos/examples/dreamcast/basic/asserthnd/asserthnd.c:46
/usr/local/home/linux/dreamcast/kos/examples/dreamcast/basic/asserthnd/asserthnd.c:69
/usr/local/home/linux/dreamcast/kos/kernel/arch/dreamcast/kernel/main.c:129
Tendremos la ruta completa de la ejecución.... mola eh?
readelf.exe
Esta utilidad nos dará la información de la estructura de los binarios (por ejemplo, si se ha compilado para SH o ARM), tanto programas como librerías Es muy fácil usarla (tiene varias opciones):
DEBUGACIÓN CON GDB Y INSIGHT
¿Insuficiente? Lo se lo se... los Dev's de
Dreamcast.es son muy exigentes, y por eso tengo que advertir que lo siguiente
ES COMPLICADO de narices, ok?
Este tutorial se centra en la compilación de
GDB (el Debug de GNU) y
Insight (una interfaz gráfica Tcl/Tk para GDB) para binarios de Dreamcast. Además, este tutorial se ha realizado en un entorno
MinGW - Win32 y usando
GCC 4.5.2, con lo cual hay una serie de pasos que pueden verse alterados según en qué entorno se compile.
Necesitarás el parche de Insight para MinGW: http://www.dreamcast.es/descargas/des...-mingw.zip
PREPARACIÓN Y NOTAS INICIALES
1. Comprueba que 'wget' esté instalado en tu sistema . Para MinGW, puedes descargarlo aquí:
http://downloads.sourceforge.net/ming...RT.tar.bz2
2. GCC 4.5.2 necesita GDB 7.0.50 o superior. Si intentas compilar GDB 6.7.1 (la versión por defecto en KOS)... fallará :(
Si sólo se quiere compilar GDB (sólo para juarcors!):
a. Abre el Makefile (kos/utils/dc-chain) y cambia la versión de GDB a 7.0.50 (testeada y funcionando), o 7.2.
b. En (kos/utils/dc-chain) ejecuta:
make gdb
c. Tómate un café / cerveza / lo que sea, y espera a que se compile. Si todo ha ido OK, tendrás un nuevo fichero
sh-elf-gdb.exe.
Si quieres compilar Insight (recomendado)
1. Al compilar Insight, también compilarás GDB + Tcl/Tk.
2. La versión de Insight va a la par con la de GDB (ej. Insight 7.2 quiere decir que lleva GDB 7.2).
3. Cualquier versión de Insight
en limpio fallará la compilación en un entorno
MinGW.
4. La versión 7.0.50 de Insight (snapshot) me funcionó. Probé la última CVS 7.2 pero daba errores. Así que usaré esta versión en el How-to.
COMPILAR INSIGHT
1. Descarga manualmente esta versión de Insight: insight-weekly-CVS-7.0.50-20091130.tar.bz2 en la carpeta dc-chain. Puedes obtenerla de:
ftp://sourceware.org/pub/insight/snap...30.tar.bz2
2. Renombra el fichero a: insight-7.0.50.tar.bz2
3. Descomprime todo en la carpeta
dc-chain (es decir, habrá una nueva carpeta
src dentro de dc-chain).
4. Descarga el
parche para MinGW, descomprime el contenido en la carpeta
dc-chain, y aplica el parche:
*
patch -p1 -i insight-mingw.patch
5. Ahora, renombra la carpeta 'src' a: 'insight-7.0.50'
6. Abre el Makefile y cambia la versión de Insight a: 7.0.50
7. Crea el siguiente fichero
fake para engañar al Makefile:
*
touch unpack_insight_stamp
8. Por fin, ya podemos compilar (y cruzar los dedos)!
*
make insight
El proceso es bastante lento (menos que compilar una toolchain, pero suficiente para dar un paseo). Si todo va bien, tendrás dos nuevos ejecutables:
sh-elf-gdb.exe and sh-elf-insight.exe.
COMPILAR DC-TOOL (1.0.5)
¿Cómo funciona el Debugger? Más o menos de esta forma:
1. Preparas tu binario para que se pueda debuggar.
2. Lo lanzas a la consola. Esta se queda esperando una conexión GDB.
3. Desde tu PC, lanzas el Debugger y te conectas a la consola. Hecho esto, ya puedes empezar con el Depurador.
Pero antes de lanzarte a la aventura, tienes que compilar DC-TOOL (sea Serial o IP). Este GDB sólo funcionará con la
última versión de dc-tool. Remarco lo de última versión porqué no funcionará con ninguna de las versiones binarias que hay por Internet. Necesitas compilar dc-tool-ip (o dc-tool-serial) con tu nueva y flamante toolchain, y luego quemar en un CD el binario de Dreamcast (carpeta make-cd).
0 ) GIT:
git clone git://git.code.sf.net/p/cadcdev/dcload-ip
1 ) En el Makefile.cfg, añade una librería más y cambia los paths. Debería ser algo así:
# MinGW
# these must point to your sh-elf bfd, not the system one
BFDLIB = -L/usr/sh-elf/lib -lbfd -lintl -liberty -lws2_32 -lwsock32
BFDINCLUDE = /usr/sh-elf/include
1) Descomenta las partes que se requieren para CygWin, y comprueba los paths.
Para Ubuntu
>> sudo apt-get install libelf-dev
Para Mac OS X
MacPorts dispone de la librería libelf, luego es cuestión de editar el Makefile y apuntar los paths al directorio de libelf de Macports.
En general
2 ) Recuerda de comprobar otras configuraciones (como la IP de la Dreamcast en dc-tool-ip). Despúes:
make y
make install
3 ) Si quieres usar BootDreams para quemar el binario de Dreamcast, antes tienes que usar la herramienta de
scramble al fichero 1st_read.bin:
http://mc.pp.se/dc/files/scramble.c
PREPARAR EL CÓDIGO PARA DEBUGAR
OK, ahora que ya tienes el
Insight seguimos con un pequeño ejemplo. Abre el fichero que contiene el main{}. Añade la función gdb_init(); al principio del main{} y añade #include <arch/gdb.h> en cualquier parte de tu código que se compile.
Un pequeño ejemplo:
#include <kos.h>
#include <arch/gdb.h>
int main(int argc, char **argv)
{
gdb_init();
printf("\nHello world!\n\n");
return 0;
}
El próximo paso es añadir
-g a tu línea de compilación en tu Makefile. Esto sólo es necesario si no usas KOS_CFLAGS ya que el -g ya se incluye por defecto.
Ya puedes compilar tu proyecto. Recuerda no eliminar el ELF, ya que contiene la información de debug.
SUBIENDO UN BINARIO Y USAR INSIGHT
1. Arranca la Dreamcast con el boot CD del dc-tool-ip (que has compilado del SVN).
2. Sube el binario de esta forma (si usas la versión IP):
*
dc-tool-ip.exe -g -t 192.168.0.13 -x hello.elf
3. Una vez el binario haya sido enviado, dc-tool te dirá "
waiting for gdb client connection." (Nota: Asegúrate de poner la -g al principio).
4. Ejecuta Insight en otra ventana:
sh-elf-insight.exe
5. File -> Open, y selecciona el ELF que acabas de subir. Si ves código fuente reconocible es buena señal, sino quiere decir que no se añadió la información de debug a tu binario cuando lo armastes.
6. Puedes marcar los breakpoints pulsando en los "-".
7. Finalmente, ves a
Run -> Connect to target. En la ventana "Connection" pon los siguientes campos:
dc-tool IP:
Target: GDBserver/TCP
Hostname: empty
Port: 2159
dc-tool Serial:
Target: GDBserver/Serial
Baud Rate: same baudrate used for dc-tool
Port: 2159
Después pulsa OK y a disfrutar!
Nota: No necesitas abrir ningún puerto de tu router para que se pueda establecer la conexión.
VER DEBUG MSG DE KOS
¿Sabías que... puedes activar tu tele como debugger y ver los mensajes que lanza KOS de debug con esto?
, I found that the problems are apparently caused by how the Windows firewall handles UDP connections. If a UDP connection is idle for more than 60 seconds, it's removed from the NAT and blocked, even if it's still kept open. Adding an exception to the firewall seems to have fixed this.
