you need to have a copy of the program you want to debug.
gdbserver does 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 |
gdbserver waits 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.txt |
The 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 gdbserver is 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, 23 is
reserved for telnet).[1] You must use the same port number with the host gdb
target remote command.
On some targets, gdbserver can also attach to running programs.
This is accomplished via the -attach argument. The syntax is:
target> gdbserver comm --attach pid |
pid is the process ID of a currently running process. It isn't necessary
to point gdbserver at a binary for the running process.
