Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Visual Studio: debug information in release build

I'm tempted to include debug information in my release builds that go out to customers. As far as I see the only down side is 25% increase in the binary file size. The advantage is that I can get an immediately usable crash dump, much easier to analyze. I'm willing to live with the 25% increase. Are there any other disadvantages I'm missing?

This is a C project and all I want to do is Linked/Debugging/Generate Debug Info

like image 219
MK. Avatar asked Jun 15 '11 20:06

MK.


People also ask

What is debug build and release build?

Debug build and release build are just names. They don't mean anything. Depending on your application, you may build it in one, two or more different ways, using different combinations of compiler and linker options.

How do I change debug to release in Visual Studio?

On the toolbar, choose either Debug or Release from the Solution Configurations list. From the Build menu, select Configuration Manager, then select Debug or Release.

How do I know if a build is debug or release?

The solution from Illegal Argument is based on the value of the android:debuggable flag in the manifest. If that is how you wish to distinguish a "debug" build from a "release" build, then by definition, that's the best solution.

What is difference between debug and release in Visual Studio?

By default, Debug includes debug information in the compiled files (allowing easy debugging) while Release usually has optimizations enabled. As far as conditional compilation goes, they each define different symbols that can be checked in your program, but they are language-specific macros.


1 Answers

The size of the executable should increase much less than 25%.

I'm actually a little surprised that it increases much at all, but some quick tests show that at least one large example project (ScummVM) increases the .exe from 10,205,184 bytes to 10,996,224 bytes just by adding the /DEBUG option to the link step (about an 8% increase). /DEBUG is specified using the "Linker | Debugging | Generate Debug Info" option in the IDE. Note that this settings should have no effect on the optimizations generated by the compiler.

I know that a pointer to the .pdb file is put in the executable, but there's not much to that. I experimented a bit and found that enabling the /OPT:REF linker option changed the size difference to 10,205,184 vs. 10,205,696. So the non /DEBUG build stayed the same size, but the /DEBUG build dropped to only 512 bytes larger (which could be accounted for by the pointer-to-.pdb - maybe the linker rounds to some multiple of 512 or something). Much less than 1% increase. Apparently, adding /DEBUG causes the linker to keep unreferenced objects unless you also specify /OPT:REF. ("Linker | Optimization | References" option in the IDE).

The program will run fine without the .pdb file - you can choose to send it to customers if you want to provide a better debugging experience at the customer site. If you just want to be able to get decent stack traces, you don't need to have the .pdb file on the customer machine - they (or some tool/functionality you provide) can send a dump file which can be loaded into a debugger at your site with the .pdb file available and get the same stack trace information port-mortem.

Of course, one thing to be aware of is that you'll need to archive the .pdb files along with your releases. The "Debugging Tools for Windows" package (which is now distributed in the Windows SDK) provides a symbol server tool so you can archive .pdb files and easily retrieve them for debugging.

The only drawback that I can think of to distributing .pdb files is that it can make reverse engineering your application easier, if that's a concern for you. Note that Microsoft distributes symbols for Windows (using a public symbol server - as well as packages of the full symbols sets for some specific releases). However, the symbols they distribute do get run through a sanitizing step that removes certain items they consider sensitive. You can do the same (or similar) using the linker's /PDBSTRIPPED option ("Linker | Debugging | Strip Private Symbols" in the IDE). See the MSDN documentation for details on what the option removes. If you're going to distribute symbols, it's probably appropriate to use that option.

like image 69
Michael Burr Avatar answered Oct 06 '22 02:10

Michael Burr