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
#. If <data> starts with two characters
:, 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
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
GDB can then transmit the next
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
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.
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
XXXXXXXXis 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
LLLLis length. A sample packet would look like
$m00005556,0024#. This would request 24 bytes starting at address 00005556 returns
XXXXXXXXis 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.
AAAAAAAAis the starting address,
LLLLis the number of bytes to be written, and
XXXXXXXXis value to be written. A sample packet would look like
NAKfor an error.
NAKis also returned when only part of the data is written.
AAAAAAAAis address to resume execution at. If
AAAAAAAAis omitted, resume at the curent address of the
pcregister. returns the same replay as
last signal. There is no immediate replay to
contuntil the next breakpoint is reached, and the program stops executing.
AA..AAis address to resume If
AA..AAis omitted, resume at same address. returns the same replay as
last signal. There is no immediate replay to
stepuntil the next breakpoint is reached, and the program stops executing.
AAis 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
AAis the signal number.
nnis the register number.
XXXXXXXXis the register value.
AAis the exit status. This is only applicable for certains sorts of targets.
$#<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.
AAfor a match with pattern PP and mask
MMare 4 bytes.
Responses can be run-length encoded to save space. A
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
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
continue command is issued
to the backend, and control returns from the breakpoint routine to the
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
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
Go to the first, previous, next, last section, table of contents.