Remote Cross-Platform Debugging with GDB

Linux-based devices can use gdb and gdbserver to be able to debug an application remotely using gdb. So, given that a corresponding platform-specific version of gdbserver is running on multiple Linux devices, you can run gdb on your Linux PC (or on another Linux device) and debug the application that is running on one of the (other) Linux devices. A common alternative is to use ssh to connect to the remote device and then run gdb locally. However, there may be circumstances where the remote device doesn’t have enough resources (CPU, memory) and using remote gdb just may work.

With all things said and for security reasons, I recommend encrypting your gdb link by sending it over an SSH tunnel if you need to go through a public network to connect to your remote device.

To get started, you only need gdb and gdbserver.

The version on a Linux distribution is for “native” x86-linux, where the host and target are the same platform: e.g. host = x86-linux and target = x86-linux.

In this example, the remote device is going to be PowerPC-based and the local device is going to be a Linux PC. Gdb and gdbserver will be built accordingly. Debugging remote devices with other CPU-architectures is simply a matter of setting the configuration of gdbserver and this will be explained below.

Building GDB and GDBServer

Step 1: Download and extract the GDB source code tarball to your Linux PC.

mkdir ~/gdb-build
cd ~/gdb-build

Copy the GDB source code tarball to ~/gdb-build and then extract it.

tar -tjvf gdb-x.x.tar.bz2

You should now have a directory called ‘’gdb-x.x’’ where ‘x.x’ is the version of gdb that you downloaded.

Step 2: Create the directories where you are going to build GDB and GDBSERVER

mkdir ~/gdb-build/ppc-gdb
mkdir ~/gdb-build/ppc-gdbserver

Step 3: Build the GDB executable

cd ppc-gdb
../gdb-6.5/configure --srcdir=../gdb- --host=x86-linux --target=powerpc-linux
make

The Gdb executable is now created and is at the location ~/gdb-build/ppc-gdb/gdb/gdb

Step 4: Build the GDBSERVER executable

cd ../ppc-gdbserver

Add the gcc cross-compiler location to your system path variable $PATH. If you’re using Bash shell, you could add the following entry to your .bash_profile or your .bashrc if that file does not exist. Here is an example, but your path may be different.

PATH=/usr/local/powerpc-linux/gcc-3.4.3-glibc-2.3.3/bin:$PATH

Then start another Bash session.

bash

Create a variable called CROSS_COMPILE.

CROSS_COMPILE=powerpc-linux- ../gdb-/gdb/gdbserver/configure --srcdir=../gdb-/gdb/gdbserver --host powerpc-linux

Then build the GDBServer executable

make

Running GDB and GDBServer

Step 5: Copy GDBServer to the PowerPC (remote) platform, then run it from there. The host IP and port is that of the PowerPC and MyApplication is your application.

gdbserver 192.168.1.110:1234 MyApplicationOnPowerPC

Step 6: Go back to the host PC and run the cross-debugging version of GDB in the ppc-gdb directory.

gdb

Step 7: Target remote from gdb. The IP address is that of the remote device.

(gdb) target remote 192.168.1.110:1234

Step 8: Do continue (cont) instead of run. Otherwise you get some message about Inferior Processes.

(gdb) cont

Step 9: If you get halted by a SIG32 signal, just do this for the appropriate signals to stop them from interrupting the debugger.

(gdb) handle SIG32 nostop [noprint]

Now, it should be up and running.

What if it doesn’t work?

To debug a cross-compiled binary running on a different target, your local gdb will need access to all binaries used by the remote program. That includes system shared libraries like libld.so, etc. If you DON’T provide the correct shared libraries to gdb, it will try to load your own LOCAL copies of the shared libraries. These obviously do not match up against the remote program, and you will have problems. This is why breakpoints won’t work right and the program will exit unexpectedly, and that may be the source of more SIG32 signals mentioned above. The easy way to fix this is to go to the remote (PowerPC) machine and tar up all shared libraries like so:

cd /
tar -cvf /tmp/powerpc_binaries.tar $(find -name \\\\*.so\\\\*)

Then on your local machine(Linux PC), untar those binaries somewhere like: /tmp/powerpc_binaries/*

mkdir /tmp/powerpc_binaries
tar -xvf /tmp/powerpc_binaries/

Now, when you start up gdb, follow this sequence:

Step 1: Start up your PowerPC program inside gdbserver at the remote PowerPC side, like before.

Step 2: Start up gdb locally (from Linux PC) like before.

Step 3: Turn verbose on (this will tell you where modules are being loaded from)

(gdb) set verbose on

Step 4: Tell gdb where to look for binaries with absolute paths:

(gdb) set solib-absolute-prefix /tmp/powerpc_binaries

Step 5: Tell gdb where to look for any binaries that couldn’t be found by absolute path in the above root.

This is useful if your application loads modules at runtime — and in general for any shared libraries and modules that cannot be found in the above root. These are library files that may be created specifically for your application that runs on your remote (PowerPC) device.

(gdb) set solib-search-path ../lib

Step 6: Now specify the remote target like before.

Step 7: Now add your breakpoints as desired

Step 8: Tell the program to continue running

(gdb) cont