I’m trying to find a way to debug core files sent to me from released versions of my software (c++ code compiled with gcc). Ideally, I’d like to be able to deploy release builds, and keep debug builds on hand to use for debugging, so I have symbol tables, etc.
My problem is that (as I understand it) the debug and release builds are not guaranteed to be the same – so a core file from the field may just look like garbage when I fire up gdb and point to my debug executable.
Is there a way around this (and here’s the catch) without impacting size or performance of my released software? It’s a large application, and performance of the debug build is probably not acceptable to customers. I’ve looked at suggestions to build once (debug), then strip symbol tables and ship that as the release build, but I’m going to see a performance hit with that approach, won’t I?
Does anyone have suggestions for things they’ve tried or currently use that address this problem?
Thanks!
You can compile and link with optimization turned on and still generate debug symbols (
-O3 -g) and then extract the debug symbols. This way you’d have the debug symbols around but can ship without them, and you won’t have a performance penalty or something. See How to generate gcc debug symbol outside the build target? on how to do that.