On the GDB host machine, you will need an unstripped copy of your program, since GDB needs symobl and debugging information. Start up GDB as usual, using the name of the local copy of your program as the first argument.
If you're using a serial line, you may want to give GDB the
`--baud' option, or use the
set remotebaud command
After that, use
target remote to establish communications with
the target machine. Its argument specifies how to communicate--either
via a devicename attached to a direct serial line, or a TCP or UDP port
(possibly to a terminal server which in turn has a serial line to the
target). For example, to use a serial line connected to the device
target remote /dev/ttyb
To use a TCP connection, use an argument of the form
For example, to connect to port 2828 on a
terminal server named
target remote manyfarms:2828
If your remote target is actually running on the same machine as your debugger session (e.g. a simulator of your target running on the same host), you can omit the hostname. For example, to connect to port 1234 on your local machine:
target remote :1234
Note that the colon is still required here.
To use a UDP connection, use an argument of the form
udp:host:port. For example, to connect to UDP port 2828
on a terminal server named
target remote udp:manyfarms:2828
When using a UDP connection for remote debugging, you should keep in mind that the `U' stands for "Unreliable". UDP can silently drop packets on busy or unreliable networks, which will cause havoc with your debugging session.
Now you can use all the usual commands to examine and change data and to step and continue the remote program.
Whenever GDB is waiting for the remote program, if you type the interrupt character (often C-C), GDB attempts to stop the program. This may or may not succeed, depending in part on the hardware and the serial drivers the remote system uses. If you type the interrupt character once again, GDB displays this prompt:
Interrupted while waiting for the program. Give up (and stop debugging it)? (y or n)
If you type y, GDB abandons the remote debugging session. (If you decide you want to try again later, you can use `target remote' again to connect once more.) If you type n, GDB goes back to waiting.
detachcommand to release it from GDB control. Detaching from the target normally resumes its execution, but the results will depend on your particular remote stub. After the
detachcommand, GDB is free to connect to another target.
disconnectcommand behaves like
detach, except that the target is generally not resumed. It will wait for GDB (this instance or another one) to connect and continue debugging. After the
disconnectcommand, GDB is again free to connect to another target.
gdbserver is a control program for Unix-like systems, which
allows you to connect your program with a remote GDB via
target remote---but without linking in the usual debugging stub.
gdbserver is not a complete replacement for the debugging stubs,
because it requires essentially the same operating-system facilities
that GDB itself does. In fact, a system that can run
gdbserver to connect to a remote GDB could also run
gdbserver is sometimes useful nevertheless,
because it is a much smaller program than GDB itself. It is
also easier to port than all of GDB, so you may be able to get
started more quickly on a new system by using
Finally, if you develop code for real-time systems, you may find that
the tradeoffs involved in real-time operation make it more convenient to
do as much development work as possible on another system, for example
by cross-compiling. You can use
gdbserver to make a similar
choice for debugging.
gdbserver communicate via either a serial line
or a TCP connection, using the standard GDB remote serial
gdbserverdoes not need your program's symbol table, so you can strip the program if necessary to save space. GDB on the host system does all the symbol handling. To use the server, you must tell it how to communicate with GDB; the name of your program; and the arguments for your program. The usual syntax is:
target> gdbserver comm program [ args ... ]comm is either a device name (to use a serial line) or a TCP hostname and portnumber. For example, to debug Emacs with the argument `foo.txt' and communicate with GDB over the serial port `/dev/com1':
target> gdbserver /dev/com1 emacs foo.txt
gdbserverwaits passively for the host GDB to communicate with it. To use a TCP connection instead of a serial line:
target> gdbserver host:2345 emacs foo.txtThe only difference from the previous example is the first argument, specifying that you are communicating with the host GDB via TCP. The `host:2345' argument means that
gdbserveris to expect a TCP connection from machine `host' to local TCP port 2345. (Currently, the `host' part is ignored.) You can choose any number you want for the port number as long as it does not conflict with any TCP ports already in use on the target system (for example,
23is reserved for
telnet).(4) You must use the same port number with the host GDB
target remotecommand. On some targets,
gdbservercan also attach to running programs. This is accomplished via the
--attachargument. The syntax is:
target> gdbserver comm --attach pidpid is the process ID of a currently running process. It isn't necessary to point
gdbserverat a binary for the running process. You can debug processes by name instead of process ID if your target has the
target> gdbserver comm --attach `pidof PROGRAM`In case more than one copy of PROGRAM is running, or PROGRAM has multiple threads, most versions of
-soption to only return the first process ID.
gdbserverprior to using the
target remotecommand. Otherwise you may get an error whose text depends on the host system, but which usually looks something like `Connection refused'. You don't need to use the
loadcommand in GDB when using gdbserver, since the program is already on the target.
gdbserve.nlm is a control program for NetWare systems, which
allows you to connect your program with a remote GDB via
gdbserve.nlm communicate via a serial line,
using the standard GDB remote serial protocol.
gdbserve.nlmdoes not need your program's symbol table, so you can strip the program if necessary to save space. GDB on the host system does all the symbol handling. To use the server, you must tell it how to communicate with GDB; the name of your program; and the arguments for your program. The syntax is:
load gdbserve [ BOARD=board ] [ PORT=port ] [ BAUD=baud ] program [ args ... ]board and port specify the serial line; baud specifies the baud rate used by the connection. port and node default to 0, baud defaults to 9600bps. For example, to debug Emacs with the argument `foo.txt'and communicate with GDB over serial port number 2 or board 1 using a 19200bps connection:
load gdbserve BOARD=1 PORT=2 BAUD=19200 emacs foo.txt
The following configuration options are available when debugging remote programs:
set remote hardware-watchpoint-limit limit
set remote hardware-breakpoint-limit limit
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:
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:
gdbserverinstead of linking a stub into your program. See section Using the
gdbserverprogram, for details.
The debugging stub is specific to the architecture of the remote machine; for example, use `sparc-stub.c' to debug programs on SPARC boards.
These working remote stubs are distributed with GDB:
The `README' file in the GDB distribution may list other recently added stubs.
The debugging stub for your architecture supplies these three subroutines:
handle_exceptionto run when your program stops. You must call this subroutine explicitly near the beginning of your program.
handle_exceptionto run when a trap is triggered.
handle_exceptiontakes control when your program stops during execution (for example, on a breakpoint), and mediates communications with GDB on the host machine. This is where the communications protocol is implemented;
handle_exceptionacts as the GDB representative on the target machine. It begins by sending summary information on the state of your program, then continues to execute, retrieving and transmitting any information GDB needs, until you execute a GDB command that makes your program resume; at that point,
handle_exceptionreturns control to your own code on the target machine.
handle_exception---in effect, to GDB. On some machines, simply receiving characters on the serial port may also trigger a trap; again, in that situation, you don't need to call
breakpointfrom your own program--simply running `target remote' from the host GDB session gets control. Call
breakpointif none of these is true, or if you simply want to make certain your program stops at a predetermined point for the start of your debugging session.
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.
In summary, when your program is ready to debug, you must follow these steps.
exceptionHook. Normally you just use:
void (*exceptionHook)() = 0;but if before calling
set_debug_traps, you set it to point to a function in your program, that function is called when
GDBcontinues after stopping on a trap (for example, bus error). The function indicated by
exceptionHookis called with one parameter: an
intwhich is the exception number.
Go to the first, previous, next, last section, table of contents.