18

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?

jww
  • 97,681
  • 90
  • 411
  • 885
sideproject
  • 241
  • 1
  • 2
  • 7
  • By default, CMake disables inlining partly under RelWithDebInfo under Visual Studio by using the flag `/Ob1` instead of `/Ob2` under Release. This can have a big effect on performance. – kaba Feb 07 '21 at 15:13

5 Answers5

23

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
  • 7,438
  • 1
  • 28
  • 41
  • 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](http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options). 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. – doug65536 Jun 23 '13 at 21:55
  • When using GCC, Release builds are compiled with -O3; but RelDebInfo builds are built with -O2. There's a fairly significant difference between -O3 and -O2 optimization. (Concretely, 2x faster for one of my critical test cases). – Robin Davies Oct 01 '22 at 11:07
7

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.

Community
  • 1
  • 1
Juan
  • 3,667
  • 3
  • 28
  • 32
  • 1
    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 Aug 06 '09 at 16:21
  • With compiler putting the debug info _besides_ the executable (like VC), this isn't an issue. – sbi Aug 06 '09 at 16:22
  • 1
    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 Aug 06 '09 at 16:37
  • 8
    @Juan: On Linux platforms, [`strip`](https://sourceware.org/binutils/docs/binutils/objcopy.html) and [`objcopy`](http://linux.die.net/man/1/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! – Christian Aichinger Apr 21 '15 at 15:49
5

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
  • 219,715
  • 46
  • 258
  • 445
  • 1
    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 Aug 06 '09 at 16:10
  • 2
    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 Aug 06 '09 at 16:26
  • 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). – paercebal Sep 27 '17 at 21:31
  • Also very useful when doing code optimization. Debug symbols allow you to roughly locate code to see what the compiler has generated. – Robin Davies Oct 01 '22 at 11:11
2

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.

Dženan
  • 3,329
  • 3
  • 31
  • 44
2

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

thekidder
  • 3,486
  • 1
  • 33
  • 36
  • Does debug information still leave a footprint in the executable? I thought the PDB carried all the info... – Kim Gräsman Aug 06 '09 at 16:00
  • 1
    On Linux, the information is contained in the object code in your binary and shared libraries. – Juan Aug 06 '09 at 16:11
  • On Linux the debug information can be stripped from executables and libraries delivered to customers, while retaining archive copies that do contain the symbols. – Robin Davies Oct 01 '22 at 11:12