CMake build mode RelWithDebInfo

Question

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?

Solution 1

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:

How to generate gcc debug symbol outside the build target?

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

Solution 2

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.

Solution 3

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.

Solution 4

Even when debug info is produced for release build, it is far less useful for debugging purposes than debug build. The reason is that many variables and intermediate expressions are optimized away, and are hence unavailable in the debugger.

Solution 5

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

View more solutions

Comments

[Kim Gräsman]

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.

[Juan]

On Linux, the information is contained in the object code in your binary and shared libraries.

[Kim Gräsman]

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)

[sbi]

With compiler putting the debug info besides the executable (like VC), this isn't an issue.

[sbi]

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.

[Juan]

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.

[doug65536]

gcc (4.8?) is adding support for much better debug info for optimized builds so this advice will only become more relevant. See -fvar-tracking and -fvar-tracking-assignments in the gcc documentation. In short, the debug info can now track the motion of data between memory and registers, and given a specific instruction pointer, it can know where to look for a given variable.

[Christian Aichinger]

@Juan: On Linux platforms, strip and objcopy can both strip debug information from binaries. With objcopy, you can also keep the stand-alone debug information around. Then you can seamlessly debug your release builds without having to ship debug information to customers (see --only-keep-debug), yay!

[paercebal]

While your answer was written in 2009, I have currently VS2008 on my desktop and it actually, by default (i.e. creating the projects with the wizard), produces PDBs in Release (both Win32 and Console applications).