The stub files provided with GDB implement the target side of the
communication protocol, and the GDB side is implemented in the
GDB source file
remote.c. Normally, you can simply allow
these subroutines to communicate, and ignore the details. (If you’re
implementing your own stub file, you can still ignore the details: start
with one of the existing stub files.
sparc-stub.c is the best
organized, and therefore the easiest to read.)
To debug a program running on another machine (the debugging target machine), you must first arrange for all the usual prerequisites for the program to run by itself. For example, for a C program, you need:
crt0. The startup routine may be supplied by your hardware supplier, or you may have to write your own.
The next step is to arrange for your program to use a serial port to communicate with the machine where GDB is running (the host machine). In general terms, the scheme looks like this:
GDB already understands how to use this protocol; when everything
else is set up, you can simply use the ‘
target remote’ command
(see Specifying a Debugging Target).
you must link with your program a few special-purpose subroutines that implement the GDB remote serial protocol. The file containing these subroutines is called a debugging stub.
On certain remote targets, you can use an auxiliary program
gdbserver instead of linking a stub into your program.
See Using the
gdbserver Program, for details.
The debugging stub is specific to the architecture of the remote
machine; for example, use
sparc-stub.c to debug programs on
These working remote stubs are distributed with GDB:
For Intel 386 and compatible architectures.
For Motorola 680x0 architectures.
For Renesas SH architectures.
For SPARC architectures.
For Fujitsu SPARCLITE architectures.
README file in the GDB distribution may list other
recently added stubs.
|• Stub Contents:||What the stub can do for you|
|• Bootstrapping:||What you must do for the stub|
|• Debug Session:||Putting it all together|