You can use catchpoints to cause the debugger to stop for certain
kinds of program events, such as C++ exceptions or the loading of a
shared library. Use the
catch command to set a catchpoint.
If regexp is given, then only exceptions whose type matches the regular expression will be caught.
The convenience variable
$_exception is available at an
exception-related catchpoint, on some systems. This holds the
exception being thrown.
There are currently some limitations to C++ exception handling in gdb:
$_exceptionconvenience variable rely on the presence of some SDT probes in
libstdc++. If these probes are not present, then these features cannot be used. These probes were first available in the GCC 4.8 release, but whether or not they are available in your GCC also depends on how it was built.
$_exceptionconvenience variable is only valid at the instruction at which an exception-related catchpoint is set.
libstdc++. You can use
up(see Selection) to get to your code.
catch exception Program_Error), the debugger will stop only when this specific exception is raised. Otherwise, the debugger stops execution when any Ada exception is raised.
When inserting an exception catchpoint on a user-defined exception whose
name is identical to one of the exceptions defined by the language, the
fully qualified name must be used as the exception name. Otherwise,
gdb will assume that it should stop on the pre-defined exception
rather than the user-defined one. For instance, assuming an exception
Constraint_Error is defined in package
the command to use to catch such exceptions is catch exception
exec. This is currently only available for HP-UX and gnu/Linux.
syscall[name | number]
name can be any system call name that is valid for the underlying OS. Just what syscalls are valid depends on the OS. On GNU and Unix systems, you can find the full list of valid syscall names on /usr/include/asm/unistd.h.
Normally, gdb knows in advance which syscalls are valid for each OS, so you can use the gdb command-line completion facilities (see command completion) to list the available choices.
You may also specify the system call numerically. A syscall's number is the value passed to the OS's syscall dispatcher to identify the requested service. When you specify the syscall by its name, gdb uses its database of syscalls to convert the name into the corresponding numeric code, but using the number directly may be useful if gdb's database does not have the complete list of syscalls on your system (e.g., because gdb lags behind the OS upgrades).
The example below illustrates how this command works if you don't provide arguments to it:
(gdb) catch syscall Catchpoint 1 (syscall) (gdb) r Starting program: /tmp/catch-syscall Catchpoint 1 (call to syscall 'close'), \ 0xffffe424 in __kernel_vsyscall () (gdb) c Continuing. Catchpoint 1 (returned from syscall 'close'), \ 0xffffe424 in __kernel_vsyscall () (gdb)
Here is an example of catching a system call by name:
(gdb) catch syscall chroot Catchpoint 1 (syscall 'chroot' ) (gdb) r Starting program: /tmp/catch-syscall Catchpoint 1 (call to syscall 'chroot'), \ 0xffffe424 in __kernel_vsyscall () (gdb) c Continuing. Catchpoint 1 (returned from syscall 'chroot'), \ 0xffffe424 in __kernel_vsyscall () (gdb)
An example of specifying a system call numerically. In the case below, the syscall number has a corresponding entry in the XML file, so gdb finds its name and prints it:
(gdb) catch syscall 252 Catchpoint 1 (syscall(s) 'exit_group') (gdb) r Starting program: /tmp/catch-syscall Catchpoint 1 (call to syscall 'exit_group'), \ 0xffffe424 in __kernel_vsyscall () (gdb) c Continuing. Program exited normally. (gdb)
However, there can be situations when there is no corresponding name in XML file for that syscall number. In this case, gdb prints a warning message saying that it was not able to find the syscall name, but the catchpoint will be set anyway. See the example below:
(gdb) catch syscall 764 warning: The number '764' does not represent a known syscall. Catchpoint 2 (syscall 764) (gdb)
If you configure gdb using the ‘--without-expat’ option, it will not be able to display syscall names. Also, if your architecture does not have an XML file describing its system calls, you will not be able to see the syscall names. It is important to notice that these two features are used for accessing the syscall name database. In either case, you will see a warning like this:
(gdb) catch syscall warning: Could not open "syscalls/i386-linux.xml" warning: Could not load the syscall XML file 'syscalls/i386-linux.xml'. GDB will not be able to display syscall names. Catchpoint 1 (syscall) (gdb)
Of course, the file name will change depending on your architecture and system.
Still using the example above, you can also try to catch a syscall by its number. In this case, you would see something like:
(gdb) catch syscall 252 Catchpoint 1 (syscall(s) 252)
Again, in this case gdb would not be able to display syscall's names.
fork. This is currently only available for HP-UX and gnu/Linux.
vfork. This is currently only available for HP-UX and gnu/Linux.
With no arguments, this catchpoint will catch any signal that is not used internally by gdb, specifically, all signals except ‘SIGTRAP’ and ‘SIGINT’.
With the argument ‘all’, all signals, including those used by gdb, will be caught. This argument cannot be used with other signal names.
Otherwise, the arguments are a list of signal names as given to
handle (see Signals). Only signals specified in this list
will be caught.
One reason that
catch signal can be more useful than
handle is that you can attach commands and conditions to the
When a signal is caught by a catchpoint, the signal's
handle, are ignored.
However, whether the signal is still delivered to the inferior depends
pass setting; this can be changed in the catchpoint's
info break command to list the current catchpoints.