Debugging with GDB Manual HP WDB v6.3 (5900-2180, August 2012)

14.23.1 Using shared library as main program
If the main program is in a shared library and you try to load it as follows:
(gdb) symbol-file main.sl
Load new symbol table from "main.sl"? (y or n) y
Reading symbols from main.sl
done.
Things don't appear to work.
This command is not the correct thing to do. This command assumes that main.sl is loaded at
its link time address. This is not true for shared libraries.
Do not use symbol-file with shared libraries.
Instead, what you should do is to use the deferred breakpoint feature to set breakpoints on any
functions necessary before the program starts running.
(gdb) b main
Breakpoint 1 (deferred) at "main" ("main" was not found).
Breakpoint deferred until a shared library containing "main" is loaded.
(gdb) r
Once the program has started running, it will hit the breakpoint. In addition, the de- bugger will
then already know about the sources for main, since it gets this information when the shared library
is loaded.
14.23.2 Setting Deferred Breakpoints in Shared Library
On HP-UX, GDB automatically loads symbol definitions from shared libraries when you use the
run command, or when you examine a core file. (Before you issue the run command, GDB does
not understand references to a function in a shared library| unless you are debugging a core file.)
When you specify a breakpoint using a name that GDB does not recognize, the debugger warns
you with a message that it is setting a deferred breakpoint on the name you specified. If any shared
library is loaded with a matching name, then GDB sets the breakpoint.
For example, if you type:
`break foo'
the debugger does not know whether foo is a misspelled name or whether it is the name of a
routine that has not yet been loaded from a shared library. The debugger displays a warning
message that it is setting a deferred breakpoint on foo. If any shared library is loaded that contains
a foo, then GDB sets the breakpoint.
If this is not what you want (for example, if the name was mistyped), then you can delete the
breakpoint.
14.23.3 Using catch load
The `catch load <libname>' command causes the debugger to stop when the particular
library is loaded. This gives you a chance to set breakpoints before routines are executed.
14.23.4 Privately mapping shared libraries
In cases where you attach to a running program and you try to set a breakpoint in a shared library,
GDB may generate the following message:
The shared libraries were not privately mapped; setting a breakpoint
in a shared library will not work until you rerun the program.
GDB generates this message because the debugger sets breakpoints by replacing an instruction
with a BREAK instruction. The debugger cannot set a breakpoint in a shared library because doing
so can affect other processes on the system in addition to the process being debugged.
14.23 Debugging support for shared libraries 167