blueDonkey.org

This Web

All Webs

blueDonkey.org

Other Sites

• Background
• The Patch
  • Installation
  • Downloads
  • Older Patch Versions
• Building the Cross-Debugger
• Building the GDB Server Binary
• Remote Debugging
• Feedback

Background

This describes a patch that will re-enable remote debugging for a PowerPC target system running NetBSD. The host can be running any operating system, so long as a cross version of gdb can be built for it and the binaries that are running on the target system are available on the host as well.

This version supports debugging of the native threading provided by the scheduler activations work in the latest kernel code. It will not work with the older pth based threading.

The Patch

Installation

The patch is relative to the src directory, so it should be installed from there as follows:

patch -p0 < gdbserver-20030602.patch

In addition to the patch, one new file is required, gdbserver.mk. Download this, and copy it to the src/gnu/usr.bin/gdb/arch/powerpc directory in your source tree.

Downloads

• gdbserver-20030602.patch: GDB & gdbserver patches
• gdbserver.mk: src/gnu/usr.bin/gdb/arch/powerpc/gdbserver.mk

Older Patch Versions

• gdbserver-20030527.patch: GDB & gdbserver patches

Building the Cross-Debugger

The easiest way to build the cross debugger is to simply set the environment variable KCROSSGDB to yes, then build the tools as normal. For example:

MKCROSSGDB=yes ./build.sh -T ~/NetBSD/ibmnws/tools \
                          -O ~/NetBSD/ibmnws/obj \
                          -D ~/NetBSD/ibmnws/root \
                          -U -m ibmnws tools

Users of csh type shells, change the environment variable setting syntax as necessary.

The end result will be a gdb binary in the tools/bin directory with a name like arch--netbsd-gdb (in the case of the PowerPC based ibmnws platform shown in the example above, the debugger image will be called powerpc--netbsd-gdb and will be in ~/NetBSD/ibmnws/tools/bin

Building the GDB Server Binary

By default the build process will not generate a gdbserver binary. This patch adds a new environment variable, MKGDBSERVER which can be set to yes in order to build this binary for your target system. For example:

MKGDBSERVER=yes ./build.sh -T ~/NetBSD/ibmnws/tools \
                           -O ~/NetBSD/ibmnws/obj \
                           -D ~/NetBSD/ibmnws/root \
                           -U -m ibmnws build

The gdbserver binary will be found in the ~/NetBSD/ibmnws/root/usr/bin using the example above. My current test system mounts /usr, /lib and /libexec via NFS. It has the remainder of the standard system directories in a ram disk.

Remote Debugging

Using the remote debugger requires some planning. In particular, you will need to make sure that the appropriate binaries can be seen by the host and the target systems. The target can use stripped versions of the binaries, leaving the debug info inclusive versions on the host system. Here's the steps I went through to get remote debug a multi-threaded application (using the paths from the build commands above as an example - change to suit your installation as necessary):

• I changed the symbolic link ~/NetBSD/ibmnws/root/usr/libexec/ld.elf_so to be a relative link:

    cd ~/NetBSD/ibmnws/root/usr/libexec
    rm ld.elf_so
    ln -s ../../libexec/ld.elf_so

• In the directory with the sources and debug-info inclusive binaries, I added a .gdbinit file with the following content:

    set solib-absolute-prefix /home/johng/NetBSD/ibmnws/root
    set solib-search-path ~/NetBSD/ibmnws/root/lib/:~/NetBSD/ibmnws/root/usr/lib/

• Make sure that the cross-tools bin directory is in your path:

bash/sh:
    export PATH=~/NetBSD/ibmnws/tools/bin:$PATH

tcsh/csh:
    set path=(~/NetBSD/ibmnws/tools/bin $path)

To run an application under the debugger, start the targer side using a command line like this:

    gdbserver h:2345 application

The h:2345 represents the hostname and port number, but since gdb ignores the host name I simply use h:. You should add any arguments you application needs after the application binary since gdbserver will exec the application immediately (although it will stop it before it actually runs any of your code).

On the host side, start the debugger as follows:

    powerpc--netbsd-gdb application

Then, at the (gdb) prompt, enter the following command to attach to the target system:

    target remote ibmnws:2345

In this case both the hostname (ibmnws in the example) and the port number must be specified. You can use the IP address for the target system if it does not have a resolvable hostname. Any port number can be used, but it must match the one used in the gdbserver command line on the target system.

If all is successful you will be able to list the source code, and set breakpoints. Once the code is actually running (i.e. the startup code has been executed), you should also be able to examine the threads. Here's some output from an info threads command on a simple test application I used:

(gdb) info threads
  3 thread 22 (<no name>: active )  0x4184d8f8 in pthread_create ()
   from /home/johng/NetBSD/ibmnws/root/usr/lib/libpthread.so.0
  2 thread 21 (<no name>: running [being joined by 0])  do_one_thing (
    pnum_times=0x1826fcc) at simple_threads.c:56
* 1 thread 0 (<no name>: sleeping joining thread 21 )  do_one_thing (
    pnum_times=0x1826fcc) at simple_threads.c:56

Feedback

If you discover any problems with this patch, or have added support for any other CPU types, please add your comments here (you will need to register to do this).

-- JohnGordon - 03 Jun 2003