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

From here, we issue the set stop-on-solib-event command and continue program execution. When the application tries to execute a function from another shared library, that library is loaded. In case you are wondering, the gethostbyname() function is encountered and causes the next shared object load.

This example illustrates an important cross-development concept. The binary application (ELF image) running on the target contains information on the libraries it needs to resolve its external references. We can view this information easily using the ldd command introduced in Chapter 11, "BusyBox," and detailed in Chapter 13. Listing 15-8 shows the output of ldd invoked from the target board.

Listing 15-8. ldd Executed on Target Board

root@coyote:/workspace# ldd websdemo

libc.so.6 => /lib/tls/libc.so.6 (0x40020000)

/lib/ld-linux.so.3 (0x40000000)

root@coyote:/workspace#

Notice that the paths to the shared libraries on the target are absolute paths starting at /lib on the root file system. But GDB running on your host development workstation cannot use these paths to find the libraries. You should realize that to do so would result in your host GDB loading libraries from the wrong architecture. Your host is likely x86, whereas, in this example, the target is ARM XScale.

If you invoke your cross version of ldd, you will see the paths that were preconfigured into your toolchain. Your toolchain must have knowledge of where these files exist on your host development system. [101] It is certainly possible to pass these locations to your compiler, linker, and debugger for every invocation, but any good embedded Linux distribution will configure these defaults into the toolchain as a convenience to the developer. Listing 15-9 illustrates this. Again, we have edited the listing for readability; long paths have been abbreviated.

Listing 15-9. ldd Executed on Development Host

$ xscale_be-ldd websdemo

libc.so.6 => /opt/mvl/.../xscale_be/target/lib/libc.so.6 (0xdead1000)

ld-linux.so.3 => /opt/mvl/.../xscale_be/target/lib/ld-linux.so.3 (0xdead2000)

$

Your cross toolchain should be preconfigured with these library locations. Not only does your host GDB need to know where they are located, but, of course, your compiler and linker also need this knowledge. [102] Of course, your compiler also needs to know the location of target files such as architecture-specific system and library header files. GDB can tell you where it is configured to look for these libraries using the show solib-absolute-prefix command:

(gdb) show solib-absolute-prefix

Prefix for loading absolute shared library symbol files is

"/opt/mvl/pro/devkit/arm/xscale_be/target".

(gdb)

You can set or change where GDB searches for shared libraries using the GDB commands set solib-absolute-prefix and set solib-search-path. If you are developing your own shared library modules or have custom library locations on your system, you can use solib-search-path to instruct GDB where to look for your libraries. For more details about these and other GDB commands, consult the online GDB manual referenced at the end of this chapter in Section 15.6.1, "Suggestions for Additional Reading."

One final note about ldd. You might have noticed the addresses from Listing 15-8 and 15-9 associated with the libraries. ldd displays the load address for the start of these code segments as they would be if the program were loaded by the Linux dynamic linker/loader. Executed on the target, the addresses in Listing 15-5 make perfect sense, and we can correlate these with the /proc//maps listing of the running process on the target. Listing 15-10 displays the memory segments for this target process after it is completely loaded and running.

Listing 15-10. Memory Segments from /proc//maps on Target

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

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

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

0002e000-0005e000 rwxp 0002e000 00:00 0 [heap]

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

40017000-40019000 rw-p 40017000 00:00 0

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

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

40020000-4011d000 r-xp 00000000 00:0a 4982651 /lib/tls/libc-2.3.3.so

4011d000-40120000 ---p 000fd000 00:0a 4982651 /lib/tls/libc-2.3.3.so

40120000-40124000 rw-p 000f8000 00:0a 4982651 /lib/tls/libc-2.3.3.so

40124000-40126000 r--p 000fc000 00:0a 4982651 /lib/tls/libc-2.3.3.so

40126000-40128000 rw-p 000fe000 00:0a 4982651 /lib/tls/libc-2.3.3.so

40128000-4012a000 rw-p 40128000 00:00 0

4012a000-40133000 r-xp 00000000 00:0a 4982652 /lib/tls/libnss_files-2.3.3.so

40133000-4013a000 ---p 00009000 00:0a 4982652 /lib/tls/libnss_files-2.3.3.so

4013a000-4013b000 r--p 00008000 00:0a 4982652 /lib/tls/libnss_files-2.3.3.so

4013b000-4013c000 rw-p 00009000 00:0a 4982652 /lib/tls/libnss_files-2.3.3.so

becaa000-becbf000 rwxp becaa000 00:00 0 [stack]

root@coyote:~#

Notice the correlation of the target ldd output from Listing 15-8 to the memory segments displayed in the /proc file system for this process. The start (beginning of .text segment) of the Linux loader is 0x40000000 and the start of libc is at 0x40020000. These are the virtual addresses where these portions of the application have been loaded, and are reported by the target invocation of ldd. However, the load addresses reported by the cross version of ldd in Listing 15-9 (0xdead1000 and 0xdead2000) are there to remind you that these libraries cannot be loaded on your host system (they are ARM architecture binaries), and the load addresses are simply placeholders.

Generally the developer is presented with two different debugging scenarios when dealing with multiple threads of execution. Processes can exist in their own address space or can share an address space (and other system resources) with other threads of execution. The former (independent processes not sharing common address space) must be debugged using separate independent debug sessions. Nothing prevents you from using gdbserver on multiple processes on your target system, and using a separate invocation of GDB on your development host to coordinate a debug session for multiple cooperating but independent processes.

When a process being debugged under GDB uses the fork() system call [103] We will use the term system call, but fork() in this context is actually the C library function which in turn calls the Linux sys_fork() system call. to spawn a new process, GDB can take two courses of action. It can continue to control and debug the parent process, or it can stop debugging the parent process and attach to the newly formed child process. You can control this behavior using the set follow-fork-mode command. The two modes are follow parent and follow child. The default behavior is for GDB to follow the parent. In this case, the child process executes immediately upon a successful fork.

Listing 15-11 reproduces a snippet of a simple program that forks multiple processes from its main() routine.