Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

When GDB is invoked, it displays a banner consisting of several lines of information and then displays its compiled configuration. Listing 15-5 is an example of the GDB used for some examples in this book, which is part of an embedded Linux distribution provided by MontaVista Software configured for PowerPC cross-development.

Listing 15-5. Invocation of cross-gdb

$ ppc_82xx-gdb

GNU gdb 6.0 (MontaVista 6.0-8.0.4.0300532 2003-12-24)

Copyright 2003 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-hardhat-linux".

(gdb)

Notice the last lines of this GDB startup message. This is the configuration compiled into this version of GDB. It was compiled to execute on a Pentium (i686) PC host running GNU/Linux and to debug binary programs compiled for a PowerPC processor running GNU/Linux. This is specified by the --host and --target variables displayed by the banner text, and is also a part of the configuration string passed to ./configure when building GDB.

Now that you understand how to invoke a remote debug session using GDB on the host and gdbserver on the target, we turn our attention to the complexities of shared libraries and debug symbols. Unless your application is a statically linked executable (linked with the -static linker command line switch), many symbols in your application will reference code outside your application. Obvious examples include the use of standard C library routines such as fopen, printf, malloc, and memcpy. Less obvious examples might include calls to application-specific functions, such as jack_transport_locate() (a routine from the JACK low-latency audio server), which calls a library function outside the standard C libraries.

To have symbols from these routines available, you must satisfy two requirements for GDB :

• You must have debug versions of the libraries available.

• GDB must know where to find them.

If you don't have debug versions of the libraries available, you can still debug your application; you just won't have any debug information available for library routines called by your application. Often this is perfectly acceptable, unless, of course, you are developing a shared library object as part of your embedded project.

Look back at Listing 15-4, where we invoked GDB on a remote target. After GDB connected via the target remote command, GDB issued a two-line response:

Remote debugging using 192.168.1.141:2001

0x40000790 in ?? ()

This confirms that GDB connected to our target at the indicated IP address and port. GDB then reports the location of the program counter as 0x40000790. Why do we get question marks instead of a symbolic location? Because this is the Linux dynamic loader (ld-x.y.z.so), and on this particular platform, we do not have debug symbols available for this shared library. How do we know this?

Recall our introduction of the /proc file system from Chapter 9, "File Systems." One of the more useful entries was the maps entry (see Listing 9-16, in Chapter 9) in the per-process directory structure. We know the process ID (PID) of our target application from the gdbserver output in Listing 15-3. Our process was assigned PID 197. Given that, we can see the memory segments in use right after process startup, as shown in Listing 15-6.

Listing 15-6. Initial Target Memory Segment Mapping

root@coyote:~ # cat /proc/197/maps

00008000-00026000 r-xp 00000000 00:0e 4852444 ./websdemo-stripped

0002d000-0002e000 rw-p 0001d000 00:0e 4852444 ./websdemo-stripped

40000000-40017000 r-xp 00000000 00:0a 4982583 /lib/ld-2.3.3.so

4001e000-40020000 rw-p 00016000 00:0a 4982583 /lib/ld-2.3.3.so

bedf9000-bee0e000 rwxp bedf9000 00:00 0 [stack]

root@coyote:~#

Here we see the target websdemo-stripped application occupying two memory segments. The first is the read-only executable segment at 0x8000, and the second is a read-write data segment at 0x2d000. The third memory segment is the one of interest. It is the Linux dynamic linker's executable code segment. Notice that it starts at address 0x40000000. If we investigate further, we can confirm that GDB is actually sitting at the first line of code for the dynamic linker, before any code from our own application has been executed. Using our cross version of readelf, we can confirm the starting address of the linker as follows:

# xscale_be-readelf -S ld-2.3.3.so | grep \.text

[ 9] .text PROGBITS 00000790 000790 012c6c 00 AX 0 0 16

From this data, we conclude that the address GDB reports on startup is the first instruction from ld-2.3.3.so, the Linux dynamic linker/loader. You can use this technique to get rough ideas of where your code is if you don't have symbolic debug information for a process or shared library.

Remember that we are executing this cross readelf command on our development host. Therefore, the ld-2.3.3.so file, itself an XScale binary object, must be accessible to your development host. Most typically, this file resides on your development host, and is a component of your embedded Linux distribution installed on your host.

GDB can alert you to shared library events. This can be useful for understanding your application's behavior or the behavior of the Linux loader, or for setting breakpoints in shared library routines you want to debug or step through. Listing 15-7 illustrates this technique. Normally, the complete path to the library is displayed. This listing has been edited for better readability.

Listing 15-7. Stopping GDB on Shared Library Events

$ xscale_be-gdb -q websdemo

(gdb) target remote 192.168.1.141:2001

Remote debugging using 192.168.1.141:2001

0x40000790 in ?? ()

(gdb) i shared<<

No shared libraries loaded at this time.

(gdb) b main<<

Breakpoint 1 at 0x12b80: file main.c, line 72.

(gdb) c

Continuing.

Breakpoint 1, main (argc=0x1, argv=0xbec7fdc4) at main.c:72

72 int localvar = 9;

(gdb) i shared

From To Syms Read Shared Object Library

0x40033300 0x4010260c Yes /opt/mvl/.../lib/tls/libc.so.6

0x40000790 0x400133fc Yes /opt/mvl/.../lib/ld-linux.so.3

(gdb) set stop-on-solib-events 1

(gdb) c

Continuing.

Stopped due to shared library event

(gdb) i shared

From To Syms Read Shared Object Library

0x40033300 0x4010260c Yes /opt/mvl/.../lib/tls/libc.so.6

0x40000790 0x400133fc Yes /opt/mvl/.../lib/ld-linux.so.3

0x4012bad8 0x40132104 Yes /opt/mvl/.../libnss_files.so.2

(gdb)

When the debug session is first started, of course, no shared libraries are loaded. You can see this with the first i shared command. This command displays the shared libraries that are currently loaded. Setting a breakpoint at our application's main() function, we see that two shared libraries are now loaded. These are the Linux dynamic linker/loader and the standard C library component libc.