Remote Debugging using GDB

• Download PDF Documentation - 426.56 KB

What is Remote Debugging?

If you are trying to debug a program running on a machine that cannot run GDB in the usual way, it is often useful to use remote debugging. For example, you might use remote debugging on an operating system kernel, or on a small system, which does not have a general-purpose operating system powerful enough to run a full-featured debugger.

How Remote Debugging is Performed?

When You Need to do Remote Debugging?

Remote debugging is useful in the following scenarios:

1. When an application is running in a device where resources are very limited and when you would like to debug it (for fast operation)
2. For debugging embedded applications with limited support tools.

An Example Debug Setup

I will take an example to explain the remote debugging in details. Imagine you want to debug an application in a target PowerPC Linux machine from an x86 Linux machine. Tools required for the above scenario.

Host side (Here client is Linux x86 machine)

1. Standard DDD for Graphical interface for easy debugging.
2. Gdb which supports the target platform. (In this case, gdb should have support for PowerPC). You can check the supported architectures as shown below:

   

3. Compiled binary with debug information (compiled with ‘-g’ option for the target PowerPC)

Target Side

1. Compiled binaries (obviously). These binaries can be with or without debug information.
2. Gdbserver for the target device.

The Debug Setup will look like this:

Debug setup sequence (TCP/IP)

1. Launch application and gdbserver in the target device.
   E.g. “gdbserver 192.168.0.30:10000 myapplication”
2. Launch DDD in the Linux machine. Ignore warnings.
3. Now connect to the gdbserver in the target device.
   E.g. “target extended-remote 10.47.199.199:10000 myapplication”
4. Press (or type) continue as application is already started in the target device. (Don’t press run). Put breakpoint wherever you need and enjoy.

Notes

1. GDB searches by default in two directories for source files during debugging. $cdir – compiled directory and $cwd – current working directory. If you are using a cross compiler and compiling the binaries in another machine, the $cdir path will not be valid. In that case, you can add additional path for source. Or you can change directory to the location of the source. This is very important especially if you have many shared libraries in different directories.

   

2. When you start gdb and attach to a remote gdbserver, you must 'continue' rather than 'run', as the program is already started in the target device.
3. It's ok to run a stripped binary on the remote system as long as you keep the unstripped binary around for use by gdb on the local system. This is pretty important, since unstripped binaries compiled with -g can be too big to fit on some embedded devices.
4. If multiple users are there in the same target machine (as in the case of our project), contact system administrator to create debug port for all users.

History

• 29^th July, 2006: Initial post