RES: Remote GDB with SPARC

[Fabricio de Novaes Kucinskis]

Hello Yan,


Here we use GDB with an ERC32 processor (SPARC V7). We started with the
"rdbmon" developed some years ago by Jiri Gaisler, over the original gdbmon.
It is GNU, and perhaps it is available at its site: www.gaisler.com

This remote debugger doesn't use RTEMS interrupt catching, but a "raw"
schema. We mixed the debugger code with the RTEMS initialization code so,
depending on a #define, we install or not the GDB trap handlers.

I think you should take a look at Gaisler' monitor.
Regards,


Fabricio de Novaes Kucinskis - DEA / INPE
-----------------------------------------
Grupo de Supervisao de Bordo - SUBORD
Divisao de Eletronica Aeroespacial
Instituto Nacional de Pesquisas Espaciais



-----Mensagem original-----
De: rtems-users-bounces at rtems.org
[mailto:rtems-users-bounces at rtems.org]Em nome de Yan Brenman
Enviada em: quinta-feira, 16 de novembro de 2006 19:18
Para: rtems-users at rtems.org
Assunto: Remote GDB with SPARC


Hi,

can somebody please provide any references on making GDB work with RTEMS
application on the SPARC target?

Specifically:
1. Were you using a sparc-stub.c provided with the GDB source package (we
are using 5.2) or some other stub?
2. Were you installing the trap handler "raw" (straight to the trap table)
or using RTEMS API (like for example "rtems_interrupt_catch")?
	2.1  Obviously if you were installing it using the RTEMS call all the
assembly "ISR wrapper" code had to be striped.
3. What were you using for serial I/O (assuming serial communication with
the target) while inside of the GDB trap handler? Were you using RTEMS
Termios Console Driver APIs (which are pretty much standard "C" I/O function
calls) or you had to bypass it and talk directly to the serial driver?
4. If you installed the trap handler using RTEMS call how did you get around
the problem of RTEMS not allowing any serial I/O while inside of the ISR?

Here in a few words what we did:
1. We used sparc-stub.c from the GDB-5.2 source as a starting point (but at
the end got read of almost half of it).
2. We used RTEMS Termios Console APIs for serial I/O (which is basically
getc and putc).
3. Since we used Termios we had to install the trap handlers using RTEMS
"rtems_interrupt_catch" routine.
4. We got around the problem of not been able to do serial I/O from the ISR
by setting _Thread_Dispatch_disable_level (a flag RTEMS uses to track if you
are in the ISR) to 0 (ugly hack).

We got it working with a small RTEMS application running on the target.
Unfortunately once the code got integrated into a bigger app with multiple
interrupt handlers and other stuff it behaves weird. In particular "continue
from the current address" doesn't work. Everything seems to fine - execution
of the code "stops" on the precompiled trap (invoked by the menu item),
jumps to the preinstalled GDB handler routine and advances PC and NPC one
instruction forward. But then return from the trap handler on "continue"
causes the code to loose control and eventually got reset by the watchdog.

Any input would be greatly appreciated.

Thanks
Yan

_______________________________________________
rtems-users mailing list
rtems-users at rtems.com
http://rtems.rtems.org/mailman/listinfo/rtems-users