1

According to lothar's answer at How to generate gcc debug symbol outside the build target, I can create a two part executable - the stripped executable and the debug information file.

After creating the stripped executable and the debug information file, I install the executable as normal (with make install). But I'm not sure what to do with the debug information file for Debian/Ubuntu.

I have two questions related to debugging the executable with GDB or LLDB (if debugging is needed):

  • What is the name of the debug information file on Debian/Ubuntu? Is there a convention to follow so the debugger associates them with the executable automatically?

  • Where do I place the the debug information file on Debian/Ubuntu? What is the location so the debugger finds them when debugging the executable?

Here's a related question for a different platform: Debug information file conventions for Red Hat/Fedora? It would also be helpful to know the same for OS X since I work on it on occasion.

Community
  • 1
  • 1
jww
  • 97,681
  • 90
  • 411
  • 885

1 Answers1

2

Both Fedora and Ubuntu follow the convention described in Debugging Information in Separate Files.

Gdb first retrieves the filename present in the executable's .gnu_debuglink section. .gnu_debuglink doesn't include any directory names. Gdb then looks for a file named (if I may use shell syntax) $(dirname $executable)/$debuglink, then /usr/lib/debug/$(dirname $executable)/$debuglink, for the debugging information. (It actually looks in a couple alternative locations; the documentation linked to above has more info.)

The debugging information for a distro-supplied executable can be found in, for example, /usr/lib/debug/usr/sbin/apache2 on Ubuntu or /usr/lib/debug/usr/sbin/httpd.debug on Fedora. (Fedora adds a .debug extension, making it easy to place the file with the debugging information in the same directory as the executable, if you wish.)

The directory /usr/lib/debug is compiled into gdb at build time, but the gdb user can change it using the set debug-file-directory dirpath1:dirpath2:... command.

If you're also interested in making the source code available to gdb:

Gdb looks for the source code in the compilation directory (which it retrieves from the debugging information's DW_AT_comp_dir attributes) or the current working directory. The user can use a variety of gdb commands described in Specifying Source Directories to adjust this.

Fedora's *-debuginfo packages include both the debugging information and the source code. The source code gets installed under /usr/src/debug, and the debugging information in the file under /usr/lib/debug includes a DW_AT_comp_dir attribute with the directory pathname, such as /usr/src/debug/httpd-2.4.10. There can be multiple DW_AT_comp_dir attributes if the executable was built from multiple compilation units.

Ubuntu's *-dbg packages don't include the source code, in my experience, but users can download the source into the current working directory with the command apt-get source .... The debugging information's DW_AT_comp_dir attribute is something like /build/buildd/apache2-2.4.7.

Mark Plotnick
  • 9,598
  • 1
  • 24
  • 40
  • *".gnu_debuglink doesn't include any directory names."* - that's interesting. The man pages for [`objcopy(1)`](http://sourceware.org/binutils/docs/binutils/objcopy.html) specifically calls out the path too (`path-to-file`), and not just the filename. I took that to mean the full filename (including path), and not just the path, and not just the filename. – jww Mar 02 '15 at 01:36
  • 1
    @jww Interesting. The gdb documentation says "The section must contain a filename, with any leading directory components removed, followed by a zero byte, zero to three bytes of padding, as needed to reach the next four-byte boundary within the section, and a four-byte CRC checksum." Maybe the definition of the section has changed over the years. I looked at the code in gdb that uses this, and it always concatenates the gnu_debuglink contents onto the end of a pathname. If the debuglink is a relative pathname, that can work, but if it's an absolute pathname, it isn't going to work as intended. – Mark Plotnick Mar 02 '15 at 02:13
  • Haha! Yeah, this is a mess. After three days of knob turning and testing, I was never able to get `objcopy` and `--add-gnu-debuglink` to actually work in practice with GDB and a distro's `/usr/lib/debug`. I think its a myth or on someone's wish list. Its really a shame for the user, though. I genuinely wanted to set things up correctly so things "just work" for the user without the need to add directory paths under GDB. – jww Mar 02 '15 at 02:18
  • Can you point me to the GDB source code (or provide the file and line number). Since I'm complaining, I should offer a patch to actually fix it... I don't expect them to take it (open source projects rarely do), but I think it warrants an offer because its so damn broken at the moment. – jww Mar 02 '15 at 02:21
  • 1
    It certainly works for the distro maintainers; I can debug the distro-supplied `glibc` at the source-code level on Ubuntu and Fedora. If you want to look at gdb, it's in `symfile.c`. Look for occurrences of `debuglink`. – Mark Plotnick Mar 02 '15 at 02:27
  • what tools do the distro maintainers use? I'm only ware of `objcopy` and `strip` for this, and they may be the wrong tools. Perhaps that's why I am failing so miserably. – jww Mar 02 '15 at 02:34
  • I don't know what tools the distro maintainers use for this. – Mark Plotnick Mar 02 '15 at 02:48
  • 1
    I looked at the source code. The answer for your first comment is... `objcopy` calls `bfd_create_gnu_debuglink_section()`, which removes the directory components from the debuglink pathname. – Mark Plotnick Mar 04 '15 at 00:10