• DistroAdvice

Advice for distributions

GDB has a number of features that either require special work by distributions to support, or that are of special interest to distributions. This page collects these into a checklist so distros can be sure to provide the best debugging support to their users.

1. sys/sdt.h probes

A number of system libraries have <sys/sdt.h> probes built-in. GDB has built-in knowledge of a few of these probes, which it uses to provide a better debugging experience to users. In particular:

• libgcc has hooks used by GDB to handle unwinding nicely. This lets things like "next over throw" work.

• libstdc++ has hooks used by GDB to implement "catch throw" and some other features specifically related to C++ exceptions. ML thread (same thread as previous bullet)

• glibc has hooks used by GDB to handle longjmp gracefully (even in the presence of PC obfuscation) and an improved interface with the runtime linker. See LinkerInterface.

See this ML thread re: the exceptions/unwinding/longjmp probes.

While <sys/sdt.h> came from the SystemTap project, it is really more of a GCC- and ELF-feature, consisting of just a couple of header files. See https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation. To ensure this is used in your distro, make sure these headers are available when building the various dependent libraries, and, for glibc, ensure you specify the --enable-systemtap configure option. You can check your work using readelf -n.

2. Python "hook" activation

GDB will automatically load some Python code when the inferior loads a shared library or the like. Many system programs, like libstdc++, ship with Python code like pretty-printers and type-printers. If the distro arranges this properly, then debugging will "just work" for users without any special configuration. You can see more information in the manual.

In Fedora we arrange for GDB to look in /usr/share/gdb/auto-load for the Python "hook" files. The hook files are named after their "parent" libraries and put into this directory. For example, the libstdc++ hook file is /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.17-gdb.py.

3. build-id

The GNU toolchain supports emitting a unique "build id" into each executable or shared library. GDB knows how to look up separate debug info files using the build id. This is superior to a by-name approach because it accounts for scenarios like examining a core dump made on a different machine with different versions of libraries installed.

See the GDB documentation about build-id or the Fedora feature describing the roll-out there.

4. .gdb_index

GDB supports a special index file that can be used to speed up GDB startup and let GDB use less memory. The index is easy to create using GDB and other GNU utilities. See the GDB documentation for more information.

5. dwz

The dwz program can be used to further compress the DWARF in your separate debuginfo files. This is a semantic compressor, not just a simple gzip-style compressor; a benefit of it is that it also lets gdb use less memory at runtime.

6. Compilation flags

With -fasynchronous-unwind-tables GDB can provide backtrace any time the program crashes or any time it gets interrupted by user. For some targets it is already the default. It is needed only for optimized builds and only for -fomit-frame-pointer code.