Setting a Breakpoint in a Dynamically Linked Library

dbx automatically detects that a dlopen or a dlclose has occurred and loads the symbol table of the loaded object. Once a shared object has been loaded with dlopen() you can place breakpoints in it and debug it like any part of your program.

If a shared object is unloaded via dlclose(), dbx remembers the breakpoints placed in it and re-places them if the shared object is again dlopened, even if the application is run again. (Versions of dbx prior to 5.0 would instead mark the breakpoint as '(defunct)', and it had to be deleted and re-placed by the user.)

However, you need not wait for the loading of a shared object with dlopen()in order to place a breakpoint in it, (or navigate its functions and source code for that matter). If you know the name of the shared object that the debugee will be dlopening you can arrange for dbx to preload its symbol table into dbx by using:

You can now navigate the modules and functions in this loadobject and place breakpoints in it before it has ever been loaded with dlopen(). Once it is loaded dbx automatically places the breakpoints.

Setting a breakpoint in a dynamically linked library is subject to the following limitations:

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

2. 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.