gdb needs an unstripped copy of your program to access symbol
and debugging information. Some remote targets (see qXfer executable filename read, and see Host I/O Packets) allow
gdb to access program files over the same connection used to
communicate with gdb. With such a target, if the remote
program is unstripped, the only command you need is
remote. Otherwise, start up gdb using the name of the local
unstripped copy of your program as the first argument, or use the
gdb can communicate with the target over a serial line, or
over an IP network using TCP or UDP. In
each case, gdb uses the same protocol for debugging your
program; only the medium carrying the debugging packets varies. The
target remote command establishes a connection to the target.
Its arguments indicate which medium to use:
target remote /dev/ttyb
If you're using a serial line, you may want to give gdb the
‘--baud’ option, or use the
set serial baud command
(see set serial baud) before the
target remote tcp:host
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 for 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.
target remote udp:host
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.
target remote |command
/bin/sh; it should expect remote protocol packets on its standard input, and send replies on its standard output. You could use this to run a stand-alone simulator that speaks the remote debugging protocol, to make net connections using programs like
ssh, or for other similar tricks.
If command closes its standard output (perhaps by exiting),
gdb will try to send it a
SIGTERM signal. (If the
program has already exited, this will have no effect.)
Once the connection has been established, you can use all the usual commands to examine and change data. The remote program is already running; you can use step and continue, and you do not need to use run.
Whenever gdb is waiting for the remote program, if you type the interrupt character (often Ctrl-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.