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.
getcharfor your target system; a different name is used to allow you to distinguish the two if you wish.
putcharfor 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
Other routines you need to supply are:
void exceptionHandler (int exception_number, void *exception_address)
You must also make sure this library routine is available:
void *memset(void *, int, int)
memsetthat sets an area of memory to a known value. If you have one of the free versions of
memsetcan 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
gcc generates as inline code.
Go to the first, previous, next, last section, table of contents.