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 before the target 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 named /dev/ttyb:
target remote /dev/ttyb |
To use a TCP connection, use an argument of the form host:port or tcp:host:port. For example, to connect to port 2828 on a terminal server named manyfarms:
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 manyfarms:
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
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.
When you have finished debugging the remote program, you can use the detach command 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 detach command, gdb is free to connect to another target.
The disconnect command 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 disconnect command, gdb is again free to connect to another target.