Hacker News Reader

Comment by psykotic | Hacker News Reader

While we're complaining about the sorry state of Linux, something it's desperately lacking (for those of us who ship binary-only libraries and executables) is an equivalent of Windows's PDBs or OS X's dSYMs for post-mortem debugging without bloating the shipping binaries.

View on HN

hi. linux does have this.

you just strip the debug symbols out (and put them somewhere safe). then write a .gnu_debuglink section to the stripped ELF binary with a CRC that matches the stripped symbols.

once something bad happens: you just take the core dump, the symbols you have tucked away, and you are able to debug just fine.

Thanks to you and others for jumping in and pointing this out! There's nothing better than being corrected when it means learning something new and solving a long-standing problem.

This is great! Seems like this may have just become available in the last few years?

See http://linux.die.net/man/1/objcopy -> --only-keep-debug

Then you can open the core file as usual: gdb executable core (just be sure to have debug files in the same directory)

While not as straightforward as on Windows (which isn't developer oriented), it's possible on Linux and standard on most distributions (just look at all the -dbg packages of debian-based distributions). A little googling found these instructions involving objcopy to separate debug symbols: http://www.technovelty.org/code/debug-info.html

Have you looked at Google Breakpad? They have some support for this:

http://code.google.com/p/google-breakpad/wiki/LinuxStarterGu...

Yes please. Even for those of us who just deploy binaries we would really like to have a way to put them back together with the symbols and source.

99.9% of the time we don't need to, but in that 0.1% it makes a big difference.

Is this the symbols-embedded-in-the-binary thing? Disc space is cheap, and they don't use extra RAM.

The bloating can be extraordinary. When you're shipping libraries to discerning customers (programmers, not end users), perception really does matter.

A related issue which is more about the compiler than the operating system is that PDBs with Visual C++ on Windows are much more useful with highly optimized binaries than symbols (either embedded or separate) are with GCC-optimized binaries. This is understandable when you consider the different development cultures, but that doesn't make it any less of a problem for us. :)

Reply on news.ycombinator.com