Debugging with GDB (September 2007)

38 Debugging with 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 c ause 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 s et a catchpoint for the
exception; catchpoints on exceptions are disabled within inte ractive 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. In the case of gnu C++, exceptions are raised by calling a library function
named __raise_exception which has the following ANSI C interface:
/* addr is where the exception identifier is stored.
id is the exception identifier. */
void __raise_exception (void **addr, void *id);
To make the debugger catch all exceptions before any stack unwinding takes place, set a
breakpoint on __raise_exception (see Section 5.1 [Breakpoints; watchpoints; and excep-
tions], page 33).
With a conditional breakpoint (see Section 5.1.5 [Break conditions], page 40) that de-
pends 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.
5.1.3 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 c an delete individual breakpoints, watchpoints,
or catchpoints by sp ec ifying 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 Section 6.5 [Selecting a frame], page 53). When the innermost
frame is selected, this is a good way to delete a breakpoint where your program
just stopped.