Debugging with GDB Manual The GNU Source-Level Debugger (769148-001, March 2014)

fork A call to fork. This is currently only available for
HP-UX.
vfork A call to vfork. This is currently only available for
HP-UX.
load, load
libname
The dynamic loading of any shared library, or the
loading of the library libname. This is currently only
available for HP-UX.
unload, unload
libname
The unloading of any dynamically loaded shared
library, or the unloading of the library libname. This
is currently only available for HP-UX.
tcatch event Set a catchpoint that is enabled only for one stop. The catchpoint is
automatically deleted after the first time the event is caught.
Use the info break command to list the current catchpoints.
There are currently some limitations to C++ exception handling (catch throw and catch
catch) in GDB:
• If you call a function interactively, GDB normally returns control to you when the function has
finished executing. If the call raises an exception, however, the call may bypass the mechanism
that returns control to you and cause your program either to abort or to simply continue running
until it hits a breakpoint, catches a signal that GDB is listening for, or exits. This is the case
even if you set a catchpoint for the exception; catchpoints on exceptions are disabled within
interactive calls.
• You cannot raise an exception interactively.
• You cannot install an exception handler interactively.
Sometimes catch is not the best way to debug exception handling: if you need to know exactly
where an exception is raised, it is better to stop before the exception handler is called, since that
way you can see the stack before any unwinding takes place. If you set a breakpoint in an exception
handler instead, it may not be easy to find out where the exception was raised.
To stop just before an exception handler is called, you need some knowledge of the implementation.
With a conditional breakpoint (see “Break conditions” (page 41)) that depends on the value of
id, you can stop your program when a specific exception is raised. You can use multiple conditional
breakpoints to stop your program when any of a number of exceptions are raised.
Deleting breakpoints
It is often necessary to eliminate a breakpoint, watchpoint, or catchpoint once it has done its job
and you no longer want your program to stop there. This is called deleting the breakpoint. A
breakpoint that has been deleted no longer exists; it is forgotten.
With the clear command you can delete breakpoints according to where they are in your program.
With the delete command you can delete individual breakpoints, watchpoints, or catchpoints
by specifying their breakpoint numbers.
It is not necessary to delete a breakpoint to proceed past it. GDB automatically ignores breakpoints
on the first instruction to be executed when you continue execution without changing the execution
address.
clear Delete any breakpoints at the next instruction to be executed
in the selected stack frame (see “Selecting a frame”
(page 51)). When the innermost frame is selected, this is a
good way to delete a breakpoint where your program just
stopped.
clear function, clear
filename:function
Delete any breakpoints set at entry to the function
function.
40 Stopping and Continuing