Jump to content

Gdbserver

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Blaxthos (talk | contribs) at 16:37, 5 February 2011 (easily clarified). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

gdbserver is a computer program that makes it possible to remotely debug other programs.[1] Running on the same system as the program to be debugged, it allows the GNU Debugger to connect from another system; that is, only the executable to be debugged needs to be resident on the target system, while the source code and a copy of the binary file to be debugged reside on the developer’s local computer.

How It Works

  1. gdbserver is launched on the target system, with the arguments:
    • The path and filename of the executable to be debugged, and
    • A port number (TCP or UDP).
    It then listens for connections on the port.
  2. gdb is run on the host, with the arguments:
    • The path and filename of the executable (and any sources) on the host, and
    • The IP address and port number needed for connection to the target system.

Example for debugging a program called hello_world on a remote host ("2345" is the TCP port number):

remote$ gdbserver :2345 hello_world
Process hello_world created; pid = 2509
Listening on port 2345
local$ gdb -q hello_world
Reading symbols from /home/user/hello_world...done.
(gdb) target remote 192.168.0.11:2345
Remote debugging using 192.168.0.11:2345
0x002f3850 in ?? () from /lib/ld-linux.so.2
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x08048414 in main () at hello_world.c:10
10	        printf("x[%d] = %g\n", i, x[i]);
(gdb) 

Alternatives

Another technique for debugging programs remotely is to use a remote stub.[2][clarification needed]

In this case, the program to be debugged is linked with a few special-purpose subroutines that implement the GDB remote serial protocol. The file containing these subroutines is called a debugging stub.

See also

Notes

References

  • Andreas Zeller: Why Programs Fail: A Guide to Systematic Debugging, Morgan Kaufmann, 2005. ISBN 1-55860-866-4