Debugging Information in Separate Files

[Debugging Information in Separate Files]

　　gdb allows you to put a program's debugging information in a file separate from the executable itself, in a way that allows gdb to find and load the debugging information automatically. Since debugging information can be very large—sometimes larger than the executable code itself—some systems distribute debugging information for their executables in separate files, which users can install only when they need to debug a problem.

gdb supports two ways of specifying the separate debug info file:

• The executable contains a debug link that specifies the name of the separate debug info file. The separate debug file's name is usually executable.debug, where executable is the name of the corresponding executable file without leading directories (e.g., ls.debug for /usr/bin/ls). In addition, the debug link specifies a 32-bit Cyclic Redundancy Check (CRC) checksum for the debug file, which gdb uses to validate that the executable and the debug file came from the same build.
• The executable contains a build ID, a unique bit string that is also present in the corresponding debug info file. (This is supported only on some operating systems, notably those which use the ELF format for binary files and the gnu Binutils.) For more details about this feature, see the description of the --build-id command-line option in Command Line Options. The debug info file's name is not specified explicitly by the build ID, but can be computed from the build ID, see below.

Depending on the way the debug info file is specified, gdb uses two different methods of looking for the debug file:　　

• For the “debug link” method, gdb (1) looks up the named file in the directory of the executable file, then (2) in a subdirectory of that directory named .debug, and finally (3) under each one of the global debug directories, in a subdirectory whose name is identical to the leading directories of the executable's absolute file name.
• For the “build ID” method, gdb looks in the .build-id subdirectory of each one of the global debug directories for a file named nn/nnnnnnnn.debug, where nn are the first 2 hex characters of the build ID bit string, and nnnnnnnn are the rest of the bit string. (Real build ID strings are 32 or more hex characters, not 10.)

So, for example, suppose you ask gdb to debug /usr/bin/ls, which has a debug link that specifies the file ls.debug, and a build ID whose value in hex is abcdef1234. If the list of the global debug directories includes /usr/lib/debug, then gdb will look for the following debug information files, in the indicated order:

• /usr/lib/debug/.build-id/ab/cdef1234.debug
• /usr/bin/ls.debug
• /usr/bin/.debug/ls.debug
• /usr/lib/debug/usr/bin/ls.debug.

Global debugging info directories default to what is set by gdb configure option --with-separate-debug-dir. During gdb run you can also set the global debugging info directories, and view the list gdb is currently using.

set debug-file-directory directories

　　Set the directories which gdb searches for separate debugging information files to directory. Multiple path components can be set concatenating them by a path separator.

show debug-file-directory

Show the directories gdb searches for separate debugging information files.

Any executable file format can carry a debug link, as long as it can contain a section named .gnu_debuglink with the contents described above.

 

The build ID is a special section in the executable file (and in other ELF binary files that gdb may consider). This section is often named .note.gnu.build-id, but that name is not mandatory. It contains unique identification for the built files—the ID remains the same across multiple builds of the same build tree. The default algorithm SHA1 produces 160 bits (40 hexadecimal characters) of the content for the build ID string. The same section with an identical value is present in the original built binary with symbols, in its stripped variant, and in the separate debugging information file.

The debugging information file itself should be an ordinary executable, containing a full set of linker symbols, sections, and debugging information. The sections of the debugging information file should have the same names, addresses, and sizes as the original file, but they need not contain any data—much like a .bss section in an ordinary executable.

The gnu binary utilities (Binutils) package includes the ‘objcopy’ utility that can produce the separated executable / debugging information file pairs using the following commands:

     objcopy --only-keep-debug foo foo.debug
     strip -g foo

These commands remove the debugging information from the executable file foo and place it in the file foo.debug. You can use the first, second or both methods to link the two files:

• The debug link method needs the following additional command to also leave behind a debug link in foo:

            objcopy --add-gnu-debuglink=foo.debug foo
  

  Ulrich Drepper's elfutils package, starting with version 0.53, contains a version of the strip command such that the command strip foo -f foo.debug has the same functionality as the two objcopy commands and the ln -s command above, together.

• Build ID gets embedded into the main executable using ld --build-id or the gcc counterpart gcc -Wl,--build-id. Build ID support plus compatibility fixes for debug files separation are present in gnu binary utilities (Binutils) package since version 2.18.

参考: https://sourceware.org/gdb/download/onlinedocs/gdb/Separate-Debug-Files.html#Separate-Debug-Files