Next: Debug Session, Previous: Stub Contents, Up: Remote Stub
The debugging stubs that come with gdb are set up for a particular chip architecture, but they have no information about the rest of your debugging target machine.
First of all you need to tell the stub how to communicate with the serial port.
int getDebugChar()
getchar
for your target system; a
different name is used to allow you to distinguish the two if you wish.
void putDebugChar(int)
putchar
for your target system; a
different name is used to allow you to distinguish the two if you wish.
If you want gdb to be able to stop your program while it is
running, you need to use an interrupt-driven serial driver, and arrange
for it to stop when it receives a ^C
(‘\003’, the control-C
character). That is the character which gdb uses to tell the
remote system to stop.
Getting the debugging target to return the proper status to gdb
probably requires changes to the standard stub; one quick and dirty way
is to just execute a breakpoint instruction (the “dirty” part is that
gdb reports a SIGTRAP
instead of a SIGINT
).
Other routines you need to supply are:
void exceptionHandler (int
exception_number, void *
exception_address)
For the 386, exception_address should be installed as an interrupt
gate so that interrupts are masked while the handler runs. The gate
should be at privilege level 0 (the most privileged level). The
sparc and 68k stubs are able to mask interrupts themselves without
help from exceptionHandler
.
void flush_i_cache()
On target machines that have instruction caches, gdb requires this function to make certain that the state of your program is stable.
You must also make sure this library routine is available:
void *memset(void *, int, int)
memset
that sets an area of
memory to a known value. If you have one of the free versions of
libc.a
, memset
can be found there; otherwise, you must
either obtain it from your hardware manufacturer, or write your own.
If you do not use the GNU C compiler, you may need other standard library subroutines as well; this varies from one stub to another, but in general the stubs are likely to use any of the common library subroutines which gcc generates as inline code.