In a previous post I mentioned split debugging info.
One addendum to this is how symbols are handled. Symbols are separate to debugging info (i.e. the stuff about variable names, types, etc you get when -g is turned on), but necessary for a good debugging experience.
You have a choice, however, of where you leave the symbol files. You can leave them in your shipping binary/library so that users who don't have the full debugging info available will still get a back-trace that at least has function names. The cost is slightly larger files for everyone, even if the symbols are never used. This appears to be what Redhat does with it's system libraries, for example.
The other option is to keep the symbols in the .debug files along-side the debug info. This results in smaller libraries, but really requires you to have the debug info files available to have workable debugging. This appears to be what Debian does.
So, how do you go about this? Well, it depends on what tools you're using.
For binutils strip, there is some asynchronicity between the --strip-debug and --only-keep-debug options. --strip-debug will keep the symbol table in the binary, and --only-keep-debug will also keep the symbol table.
$ gcc -g -o main main.c $ readelf --sections ./main | grep symtab [36] .symtab SYMTAB 00000000 000f48 000490 10 37 53 4 $ cp main main.debug $ strip --only-keep-debug main.debug $ readelf --sections ./main.debug | grep symtab [36] .symtab SYMTAB 00000000 000b1c 000490 10 37 53 4 $ strip --strip-debug ./main $ readelf --sections ./main.debug | grep symtab [36] .symtab SYMTAB 00000000 000b1c 000490 10 37 53 4
Of course, you can then strip (with no arguments) the final binary to get rid of the symbol table; but other than manually pulling out the .symtab section with objcopy I'm not aware of any way to remove it from the debug info file.
Constrast with elfutils; more commonly used on Redhat based system I think.
eu-strip's --strip-debug does the same thing; leaves the symtab section in the binary. However, it also has a -f option, which puts any removed sections during the strip into a separate file. Therefore, you can create any combination you wish; eu-strip -f results in an empty binary with symbols and debug data in the .debug file, while eu-strip -g -f results in debug data only in the .debug file, and symbol data retained in the binary.
The only thing to be careful about is using eu-strip -g -f and then further stripping the binary, and consequently destroying the symbol table, but retaining debug info. This can lead to some strange things in backtraces:
$ gcc -g -o main main.c
$ eu-strip -g -f main.debug main
$ strip ./main
$ gdb ./main
GNU gdb (GDB) 7.1-debian
...
(gdb) break foo
Breakpoint 1 at 0x8048397: file main.c, line 2.
(gdb) r
Starting program: /home/ianw/tmp/symtab/main
Breakpoint 1, foo (i=100) at main.c:2
2return i + 100;
(gdb) back
#0 foo (i=100) at main.c:2
#1 0x080483b1 in main () at main.c:6
#2 0x423f1c76 in __libc_start_main (main=Could not find the frame base for "__libc_start_main".
) at libc-start.c:228
#3 0x08048301 in ?? ()
Note one difference between strip and eu-strip is that binutils strip will leave the .gnu_debuglink section in, while eu-strip will not:
$ gcc -g -o main main.c $ eu-strip -g -f main.debug main $ readelf --sections ./main| grep debuglink [29] .gnu_debuglink PROGBITS 00000000 000bd8 000010 00 0 0 4 $ eu-strip main $ readelf --sections ./main| grep debuglink $ gcc -g -o main main.c $ eu-strip -g -f main.debug main $ strip main $ readelf --sections ./main| grep debuglink [27] .gnu_debuglink PROGBITS 00000000 0005d8 000010 00 0 0 4