Filter
Top Products
14.22.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.22.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.22.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.22 Debugging support for shared libraries 211