3

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!

ndtrek07
  • 499
  • 1
  • 4
  • 8

1 Answers1

5

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.

Community
  • 1
  • 1
DarkDust
  • 90,870
  • 19
  • 190
  • 224
  • Thanks, I think that's what I'm looking for. With optimization turned on, I may still have trouble debugging due to inlining, etc, but it'll be better than nothing, right? Also as a follow-up, if I do compile with -g, but also -s, do those two options effectively cancel each other out, or does -s not remove everything added with -g? – ndtrek07 Apr 08 '11 at 17:29
  • @ndtrek07: Good question, I think `-s` does cancel `-g` as it says "string unnecessary symbols", and that includes debug symbols. – DarkDust Apr 08 '11 at 17:55