*** MOVED ***

NOTE: I have merged the contents of this blog with my web-site. I will not be updating this blog any more.


Separating Debugging Information

Debugging information in an executable usually takes up a lot of space so developers usually "strip" an executable before shipping it. This however makes it difficult to diagnose problems in your programme reported by the users, especially when a problem is only reproducible in the reporting user's environment.

Microsoft's development tools support creating a separate "Program Database" (PDB) file for an executable containing debugging information for the executable. Its diagnostic tools support reading a PDB file for an executable , if one is available, to generate a more usable diagnostic report for a fault. You ship stripped executables to your users and when they report a fault, you ask them to install the corresponding PDB files to help you get a better diagnostic report. I think that this is a nice idea and I used to wonder if the GNU toolchain would ever support something like this.

Danny Smith pointed out to me that something similar is already supported by recent versions of GDB and binutils. You can use the --only-keep-debug option of objcopy for this purpose. For example:

gcc -g hello.c
objcopy --only-keep-debug a.out a.dbg
strip --strip-debug a.out

a.dbg now has the debugging symbols and a.out has been stripped of debugging symbols. When you want to debug a.out you can use:

gdb -s a.dbg -e a.out



  1. How do Debian and Ubuntu generate the -dbg packages? These packages include just the debugging symbols for things like libgnome, nautilus, glibc, ...

  2. In Fedora this is all automated. An RPM will generate a separate -debuginfo package with no special assistance required from the packager. The resulting executables in the main package will all be stripped, but you can later install the debuginfo package to be able to debug, see symbolic stack traces, etc.


Note: Only a member of this blog may post a comment.