views:

379

answers:

4

I think that I understand the difference between Release and Debug build modes. The main differences being that in Debug mode, the executable produced isn't optimized (as this could make debugging harder) and the debug symbols are included.

While building PCRE, one of the external dependencies for WinMerge, I noticed a build mode that I hadn't seen before: RelWithDebInfo.

The difference between Debug and RelWithDebInfo is mentioned here: http://www.cmake.org/pipermail/cmake/2001-October/002479.html. exerpt: "RelwithDebInfo is quite similar to Release mode. It produces fully optimized code, but also builds the program database, and inserts debug line information to give a debugger a good chance at guessing where in the code you are at any time."

This sounds like a really good idea, however not necessarily obvious how to set up. This link describes how to enable this for VC++: http://www.cygnus-software.com/papers/release_debugging.html

Am I missing something, or does it not make sense to compile all release code as RelWithDebInfo?

A: 

As far as I'm concerned, shipping code to customers without having corresponding debug symbols stored in-house is a recipe for hair-loss when it comes to debugging production problems.

Debugging Release builds with debug symbols is rarely any different from debugging Debug builds, so I'd recommend always doing this.

That said, I don't know if there are any drawbacks. It'd be interesting to hear, if so.

Kim Gräsman
A: 

Production code doesn't need the size bloat that debugging information carries.

thekidder
Does debug information still leave a footprint in the executable? I thought the PDB carried all the info...
Kim Gräsman
On Linux, the information is contained in the object code in your binary and shared libraries.
Juan
Thanks, I didn't know that!
Kim Gräsman
A: 

Once you have tried to debug an optimized release build, you know why this is something you only want to do when there is no other way out.

Basically, I see two cases when you'll need this:

  • You have a problem that doesn't appear in debug builds, so you have to debug a release build
  • You have a crash at a customers and use the locally stored debug info to understand the crash.

I don't know about you, but I had to debug release code twice or thrice in the last decade and managed to work at companies where crashes at customer's were no issue.

Yeah, it's probably a good idea to have debug info for your release builds, too, but VS doesn't set things up this way and for the two cases in each decade where you need this it isn't worth setting this up manually every time. Since CMake gives it for free, do it.

sbi
I guess it depends what kind of code you work on -- I've had very much use for debug symbols of optimized builds. Not least because we generate a minidump at any unexpected exceptions, and that together with symbols gives us a full, readable callstack for every thread. It's a good place to start debugging anyway.
Kim Gräsman
Kim, I rarely ever see crashes. I guess it comes down to coding style. In a large project I used to work for a long time (years), there were parts where crashes where more common than in other parts and there were parts where crashes found during tests were something that happened only once in five years. The probability of crashes obviously correlated with the amount of manual resource management.
sbi
A: 

Am I missing something, or does it not make sense to compile all release code as RelWithDebInfo?

It depends on how much you trust your customer with the debugging information.

Additional Info:

gcc encodes the debugging information into the object code.

Here is the pdb equivalent for gcc:

http://stackoverflow.com/questions/866721/how-to-generate-gcc-debug-symbol-outside-the-build-target

Note, that cmake doesn't appear to support this approach out of the box.

Juan
You don't have to ship debug info to your customers (oh, unless, as you mentioned, for platforms where it's embedded in the binaries)
Kim Gräsman
With compiler putting the debug info _besides_ the executable (like VC), this isn't an issue.
sbi
I do cross platform development. I hope Visual C++ people understand the consequences of the target on other platforms. I also recommend cmake users use the cmake mailing list, because I find their written documentation incomplete.
Juan