dbx and the Dynamic Linker

19

This chapter is organized into the following sections:

Basic Concepts	page 223
Debugging Support for Shared Objects	page 224
Setting a Breakpoint in a Dynamically Linked Library	page 226

1. Program startup

At program startup, rtld runs first and dynamically loads all shared objects specified at link time. These are preloaded shared objects and commonly include libc.so, libC.so, and libX.so. (Use ldd(1) to find out what shared objects a program will load.)

2. Application Requests

The application uses the function calls dlopen(3) and dlclose(3) to dynamically load and unload shared objects or executables. dbx uses the term load objects to refer to a shared object (.so) or executable (a.out).

dbx traverses the link map to see:

• Which objects were loaded
• What their corresponding binaries are
• At what base address they were loaded

Startup Sequence

stop in printf

run

requires special consideration by dbx. Whenever you load a new program, dbx automatically executes the program up to the point where rtld has completed construction of the link map. dbx then reads the link map and stores the base addresses. After that, the process is killed and you see messages and the prompt. These dbx tasks are completed silently.

At this point, the symbol table for libc.so is available as well as its base load address. Therefore, the address of printf is known.

The activity of dbx waiting for rtld to construct the link map and accessing the head of the link map is known as the rtld handshake. The event syncrtld occurs when rtld is done with the link map and dbx has read all of the symbol tables.

With this scheme, dbx depends on the fact that when the program is rerun, the shared libraries are loaded at the same base address. The assumption that shared libraries are loaded at the same base address is seldom violated; usually only if you change LD_LIBRARY_PATH between loading of the program and running it. In such cases, dbx takes note of the new address and prints a message. However, breakpoints in the moved shared object may be incorrect.

Startup Sequence and .init Sections

The dynamic linker first maps in all the shared objects, putting them on the link map. Then, the dynamic linker traverses the link map and executes the .init section for each shared object.

dlopen() and dlclose()

When a shared object is unloaded, the symbol table is discarded and the breakpoints are marked as "(defunct)" when you request status. There is no way to automatically re-enable the breakpoints if the object is opened again on a consecutive run.

Two events, dlopen and dlclose, can be used with the when command and some shell programming, to help ease the burden of managing breakpoints in dlopen type shared objects.

fix and continue

Procedure Linkage Tables (PLT)

For dbx to handle step and next commands across PLTs, it has to keep track of the PLT table of each load object. The table information is acquired at the same time as the rtld handshake.

Three Exceptions

• You cannot set a breakpoint in a dlopen'ed library before that library is loaded by dlopen().

• You cannot set a breakpoint in a dlopen'ed "filter" library until the first function in it is called.

• When a library is loaded by dlopen(), an initialization routine named _init() is called. This routine may call other routines in the library. dbx cannot place breakpoints in the loaded library until after this initialization is completed. In specific terms, this means you cannot have dbx stop at _init() in a library loaded by dlopen.