¿Alguien ha depurado con el gdb de la GP2X?

[Puck2099]

Hola,

Ya he conseguido conectar a través del usb serie a la GP2X bajo Linux y ahora quería ponerme a depurar el Fenix a ver porque leches falla...

El caso es que he copiado el gdb que sacaron para la gp2x, pero no me muestra las líneas que se están ejecutando, sino que en su lugar aparece el mensaje:

[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]

¿Tenéis alguna idea de qué puede estar pasando? Creo que es cosa del port del gdb, pero no estoy seguro...

Saludos

[KaosOverride]

a mi se me ocurre otra forma mas rapida de usar el driver USBserial... Al cargarlo en la GP2x, genera en el /dev un puerto serie extra, no? que es el que usa el gdb para intercambiar info con el PC... Bien... manda desde la aplicacion al strout o al stderr mensajes con printf en tu aplicacion a probar, con variables, mensajes de "esta ejecutando BLABLABLA" y demas, conecta el hyperterminal de windows o cualquier otro emulador de terminal, y en al consola lo lanzas con un script que sea " ./aplica.gpe >/dev/usbserial 2>/dev/usbserial" siendo /dev/usbserial el puerto virtual creado... En el hyperterminal empezara a escupir todos los datos que le hayas puesto en los printfs... No puede fallar :)

Esto es un "derivado" de la tecnica que se usaba en MS-DOS por la escena PC, con las tarjetas graficas Hercules, cuyo modo de texto esta en otro segmento distinto al de VGA y por tanto podias escribir en el "2º monitor"


Prueba a ver que tal ;)

[Puck2099]

a mi se me ocurre otra forma mas rapida de usar el driver USBserial... Al cargarlo en la GP2x, genera en el /dev un puerto serie extra, no? que es el que usa el gdb para intercambiar info con el PC... Bien... manda desde la aplicacion al strout o al stderr mensajes con printf en tu aplicacion a probar, con variables, mensajes de "esta ejecutando BLABLABLA" y demas, conecta el hyperterminal de windows o cualquier otro emulador de terminal, y en al consola lo lanzas con un script que sea " ./aplica.gpe >/dev/usbserial 2>/dev/usbserial" siendo /dev/usbserial el puerto virtual creado... En el hyperterminal empezara a escupir todos los datos que le hayas puesto en los printfs... No puede fallar :)

Esto es un "derivado" de la tecnica que se usaba en MS-DOS por la escena PC, con las tarjetas graficas Hercules, cuyo modo de texto esta en otro segmento distinto al de VGA y por tanto podias escribir en el "2º monitor"


Prueba a ver que tal ;)

Sí, eso es lo que hacía hasta ahora, pero en el Fenix me saltaba un "segmentation fault" y necesitaba saber en qué linea cascaba.

Ahora ya sé la linea donde falla (al menos ese dato sí lo da bien), pero ni idea de porque peta ahí :(

Saludos

[NoobLuck]

Propongo que vuelques la salida del gdb como archivo de texto y accedas a la SD por medio del mass storage y vayas abriendo el archivo cada vez.

A mi me parece un error del serial por usb.

¿Por que no compilas en linux normal y ejecutas el gdb y depuras tal cual, antes de cruzar el código?

[Puck2099]

¿Por que no compilas en linux normal y ejecutas el gdb y depuras tal cual, antes de cruzar el código?

Porque en Linux de PC funciona perfectamente y en la GP2X es donde peta :(

[NoobLuck]

Y en vez de usar el serial no se podria acceder por telnet a la GP2X?
Claro que si hay que tocar la NAND yo soy el último.

[KaosOverride]

¿Por que no compilas en linux normal y ejecutas el gdb y depuras tal cual, antes de cruzar el código?

Yo si he partido del CPC Caprice 4.1.0, aparte de por consejo de A600, es porque el Caprice 4.2.0, despues de quitarle el %·$&% de historias de OpenGl (y todo para aplicar un filtro de imagen y se vea "mas bonito"..) me compilaba "guay" en DevC++/windows y Linux I386, pero me cascaba en la GP2x en una funcion del CRTC (Chipset grafico del CPC)... No se tampoco porque... pero peta... El que compile y cargue "guay" en Pc no significa "victoria" en GP2x :(

Eso si, ahora estoy loco tratando ce compilar las libm (las matematicas) por softfloat y no por FPU, como estaban mal compiladas en algun devkit inicial... Es lo unico que se me ocurre que podria dar alguna pista... Hay alguna funcion trigonometrica, de raices cuadradas, etc, en ese punto del fenix??

[Puck2099]

Eso si, ahora estoy loco tratando ce compilar las libm (las matematicas) por softfloat y no por FPU, como estaban mal compiladas en algun devkit inicial... Es lo unico que se me ocurre que podria dar alguna pista... Hay alguna funcion trigonometrica, de raices cuadradas, etc, en ese punto del fenix??

Que va, creo que tiene que ver con el puntero de pila y los registros...



p = sysproc_get (ptr[1]) ;
if (!p) gr_error ("Error: Procedimiento del sistema desconocido\n") ;
stack_ptr -= p->params ;
(*p->func) (r, stack_ptr) ;
ptr += 2 ;

La línea que peta es la marcada en negrita, lo que me mosquea de esta función es que haya definidas variables como "register int"...

Saludos

[Puck2099]

Por cierto, el error que me devuelve el gdb al petar es:


Program received signal SIGTTOU, Stopped (tty output).

¿Alguna idea?

[NoobLuck]

Que va, creo que tiene que ver con el puntero de pila y los registros...



p = sysproc_get (ptr[1]) ;
if (!p) gr_error ("Error: Procedimiento del sistema desconocido\n") ;
stack_ptr -= p->params ;
(*p->func) (r, stack_ptr) ;
ptr += 2 ;

La línea que peta es la marcada en negrita, lo que me mosquea de esta función es que haya definidas variables como "register int"...

Saludos

register int no creo que sea el problema, es un entero que se queda en el registro de instrucciones del procesador, es para optimizar el acceso al mismo. puedes quitarlo y el programa funcionaria igualmente (aunque más despacio, por que ese int se quedaria en ram y habria que copiarlo otra vez al RI para usarlo etc, etc...

no encuentro la función "sysproc_get ()" en el manual.

[Topochan]

Que va, creo que tiene que ver con el puntero de pila y los registros...



p = sysproc_get (ptr[1]) ;
if (!p) gr_error ("Error: Procedimiento del sistema desconocido\n") ;
stack_ptr -= p->params ;
(*p->func) (r, stack_ptr) ;
ptr += 2 ;

La línea que peta es la marcada en negrita, lo que me mosquea de esta función es que haya definidas variables como "register int"...

Saludos
Hola, lo que veo, p no se que es pero parece que es el que alamacena temporalente los procesos que va ejecutando, el if si esta, y luego elimina de la pila de punteros los parametros(?¿), y posteriormente ejecuta la funcion de la pila de registros con parametros r y stack_prt... no sera que si eliminamos de la pila de parametros los parametros de la funcion alomejor entra en zona de memoria no valida y adenas con los parametros no adecuados???

PD: he visto el fuente y necesita de opengl asi que va ser que no :(

[Puck2099]

Hola, lo que veo, p no se que es pero parece que es el que alamacena temporalente los procesos que va ejecutando, el if si esta, y luego elimina de la pila de punteros los parametros(?¿), y posteriormente ejecuta la funcion de la pila de registros con parametros r y stack_prt... no sera que si eliminamos de la pila de parametros los parametros de la funcion alomejor entra en zona de memoria no valida y adenas con los parametros no adecuados???

Eso había pensado yo, que entraba en una zona de memoria no asignada y petaba por eso :(


PD: he visto el fuente y necesita de opengl asi que va ser que no :(

¿Qué es lo que necesita de opengl?

Saludos

[NoobLuck]

Recibí hace poco mi consola.

Carga el modulo USB serial y abre una terminal en tu ordenador.

Cierra todos los procesos que escriban en pantalla como el gp2xmenu. (ps y kill)

ejecuta:

clear > /dev/tty0

vuelca la salida de error del gdb en tty0, las lineas que no puedes ver, deberias poder verlas ahora en la pantalla de la GP2X.

[Wave]

Al parecer peta al llamar a una funcion que aunque tiene direccion de memoria (por eso no da el error) debe estar mal echa, pero claro, si no te falla en PC debe ser algo del compilador para GP2X...
Lo de stack_ptr -= p->params ; es para reservar memoria para los parametros de p o al menos es como se hace en los compiladores, reservas un espacio en la pila para los parametros.