Debugging information in Linux ELF binaries is usually stored in the binary itself. This had been really convenient to me, for example, I always compile my openr2 library with -ggdb3 -O0. I don’t care about optimizations nor the increase in size in the binary and users can always change those flags using CFLAGS when configuring openr2. Is convenient because if my users ever get a core dump, I was able to jump right in and get a useful backtrace and examine the stack. Alternatively they could get the stack trace themselves and send it to me without worrying about anything else than launching gdb with the right arguments.
However, when you ship non-open source software or you’re just concerned with the size of all the debugging information in lots of libraries, you want to separate the debugging information from the binary holding the program/library itself. In Windows this is the default behavior you get with the well known PDB (Program Data Base) files. For Linux though, you need some tricks to get the debugging information separate. This is of course what most distributions do, they include an extra package with debugging information, so when you install a package you get just the binary code, then, if you need to debug it you download the debugging package.
If you ever need this, you can follow the instructions in this web page to get it to work:
http://sources.redhat.com/gdb/current/onlinedocs/gdb_17.html#SEC166
The way I solved it for our internal build system is just to always compile with -ggdb3 and then:
1. Create a copy of the debugging symbols in a separate binary
objcopy --only-keep-debug somelibrary.so somelibrary.so.dbg2. Remove the debugging information from the code binary.
objcopy --strip-debug somelibrary.so3. Add a reference to the code binary so gdb knows where to look for the debugging information
objcopy --add-gnu-debuglink somelibrary.so.dbg somelibrary.soThis last step is simply putting a file name reference inside the ELF binary so GDB (or some other debugger) knows which file name will have the debugging information for this .so (or an executable if that’s what you’re building). In the red hat web page more advanced techniques are explained to make sure you don’t end up with a version mismatch between the debugging information and your library or executable.
