HP gnu source-level debugger 5992-4701 manual Setting Deferred Breakpoints in Shared Library

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