Typically, either the low-level I/O routines are used for debugging, or LEDs, if present. It is much easier to use GDb for debugging an application. There are several different techniques used to have GDB work remotely. Commonly more than one kind of GDB interface is used to cober a wide variety of development needs.
The most common style of GDB backend is an exception handler for
breakpoints. This is also called a gdb stub, and is requires the
two additional lines of init code in your main() routine. The GDB
stubs all use the GDB remote protocol. When the application gets a
breakpoint exception, it communicates to GDB on the host.
Another common style of interfacing GDB to a target is by using an existing ROM monitor. These break down into two main kinds, a similar protocol to the GDB remote protocol, and an interface that uses the ROM monitor directly. This kind has GDB simulating a human operator, and all GDB does is work as a command formatter and parser.
The standard remote protocol is a simple, packet based scheme. A debug packet whose contents are <data> is encapsulated for transmission in the form:
$ <data> # CSUM1 CSUM2
<data> must be ASCII alphanumeric and cannot include characters
$ or #. If <data> starts with two characters
followed by :, then the existing stubs interpret this as a
sequence number. For example, the command g is used to read the
values of the registers. So, a packet to do this would look like
$g#67
CSUM1 and CSUM2 are an ascii representation in hex of an 8-bit checksum of <data>, the most significant nibble is sent first. the hex digits 0-9,a-f are used.
A simple protocol is used when communicating with the target. This is
mainly to give a degree of error handling over the serial cable. For
each packet transmitted successfully, the target responds with a
+ (ACK). If there was a transmission error, then the target
responds with a - (NAK). An error is determined when the
checksum doesn't match the calculated checksum for that data record.
Upon reciept of the ACK, GDB can then transmit the next
packet.
Here is a list of the main functions that need to be supported. Each data
packet is a command with a set number of bytes in the command packet.
Most commands either return data, or respond with a NAK. Commands
that don't return data respond with an ACK. All data values are
ascii hex digits. Every byte needs two hex digits to represent t. This
means that a byte with the value `7' becomes `07'. On a 32 bit
machine this works out to 8 characters per word. All of the bytes in a
word are stored in the target byte order. When writing the host side of
the GDB protocol, be careful of byte order, and make sure that the code
will run on both big and little endian hosts and produce the same answers.
These functions are the minimum required to make a GDB backend work. All other commands are optional, and not supported by all GDB backends.
g'
XXXXXXXX...
Registers are in the internal order for GDB, and the bytes in a register
are in the same order the machine uses. All values are in sequence
starting with register 0. All registers are listed in the same packet. A
sample packet would look like $g#.
GXXXXXXXX...'
XXXXXXXX is the value to set the register to. Registers are in
the internal order for GDB, and the bytes in a register are in the same
order the machine uses. All values are in sequence starting with
register 0. All registers values are listed in the same packet. A sample
packet would look like $G000000001111111122222222...#
returns ACK or NAK
mAAAAAAAA,LLLL'
AAAAAAAA is address, LLLL is length. A sample packet would
look like $m00005556,0024#. This would request 24 bytes starting
at address 00005556
returns XXXXXXXX...
XXXXXXXX is the memory contents. Fewer bytes than requested will
be returned if only part of the data can be read. This can be determined
by counting the values till the end of packet # is seen and
comparing that with the total count of bytes that was requested.
MAAAAAAAA,LLLL:XXXXXXXX'
AAAAAAAA is the starting address, LLLL is the number of
bytes to be written, and XXXXXXXX is value to be written. A
sample packet would look like
$M00005556,0024:101010101111111100000000...#
returns ACK or NAK for an error. NAK is also
returned when only part of the data is written.
cAAAAAAAAA'
AAAAAAAA is address to resume execution at. If AAAAAAAA is
omitted, resume at the curent address of the pc register.
returns the same replay as last signal. There is no immediate
replay to cont until the next breakpoint is reached, and the
program stops executing.
AA..AA is address to resume
If AA..AA is omitted, resume at same address.
returns the same replay as last signal. There is no immediate
replay to step until the next breakpoint is reached, and the
program stops executing.
?'
SAA
Where AA is the number of the last signal.
Exceptions on the target are converted to the most similar Unix style
signal number, like SIGSEGV. A sample response of this type would
look like $S05#.
AA is the signal number.
nn is the register number.
XXXXXXXX is the register value.
AA is the exit status. This is only
applicable for certains sorts of targets.
Pnn=XXXXXXXX'
nn with value XXXXXXXX.
returns ACK or NAK
other'
$#<checksum>. This way we can extend the protocol and GDB
can tell whether the stub it is talking to uses the old or the new.
tAA:PP,MM'
AA for a match with pattern
PP and mask MM. PP and MM are 4 bytes.
qXXXX'
QXXXX=yyyy'
XXXX to yyyy.
qOffsets'
Text=xxx;Data=yyy;Bss=zzz
Responses can be run-length encoded to save space. A *means that
the next character is an ASCII encoding giving a repeat count which
stands for that many repetitions of the character preceding the *.
The encoding is n+29, yielding a printable character where n >=3
(which is where run length encoding starts to win). You can't use a
value of where n >126 because it's only a two byte value. An example
would be a 0*03 means the same thing as 0000.
A GDB stub consists of two parts, support for the exception handler, and the exception handler itself. The exception handler needs to communicate to GDB on the host whenever there is a breakpoint exception. When GDB starts a program running on the target, it's polling the serial port during execution looking for any debug packets. So when a breakpoint occurs, the exception handler needs to save state, and send a GDB remote protocol packet to GDB on the host. GDB takes any output that isn't a debug command packet and displays it in the command window.
Support for the exception handler varies between processors, but the minimum supported functions are those needed by GDB. These are functions to support the reading and writing of registers, the reading and writing of memory, start execution at an address, single step, and last signal. Sometimes other functions for adjusting the baud rate, or resetting the hardware are implemented.
Once GDB gets the command packet from the breakpoint, it will read a few
registers and memory locations an then wait for the user. When the user
types run or continue a continue command is issued
to the backend, and control returns from the breakpoint routine to the
application.
GDB also can mimic a human user and use a ROM monitors normal debug
commands as a backend. This consists mostly of sending and parsing
ASCII strings. All the ROM monitor interfaces share a common set
of routines in gdb/monitor.c. This supports adding new ROM
monitor interfaces by filling in a structure with the common commands
GDB needs. GDb already supports several command ROM monitors, including
Motorola's Bug monitor for their VME boards, and the Rom68k
monitor by Integrated Systems, Inc. for various m68k based boards. GDB
also supports the custom ROM monitors on the WinBond and Oki PA based
targets. There is builtin support for loading files to ROM monitors
specifically. GDB can convert a binary into an srecord and then load it
as an ascii file, or using xmodem.
Go to the first, previous, next, last section, table of contents.