4

In visual studio there's an option called "Optimize for debugging" in the linker settings for a project:

Project Debug Options

By default it's set to "Optimize for debugging (/DEBUG)", even for the release configuration. Why is that? Does that change the built program in any way? Is there any disadvantage of having it enabled (Slower execution?)? Should I set this option to "No" before shipping a program? Or is it just to enable/disable generating the .pdb-debug file (=slower compile times when enabled)?

Silverlan
  • 2,783
  • 3
  • 31
  • 66
  • 2
    MSDN info: https://learn.microsoft.com/en-gb/cpp/build/reference/debug-generate-debug-info Basically puts out a .PDB file so you can debug the release version and/or load dumps mini-dumps into the debugger if you have them – Richard Critten Jun 09 '17 at 10:21
  • 3
    Typically you leave `/DEBUG` even for release builds, but not distribute generated `.pdb` file along with your application. – user7860670 Jun 09 '17 at 10:22
  • The default for release is "Maximize Speed (/O2)". –  Jun 09 '17 at 10:24
  • 1
    @manni66 OP is asking about the linker switch not the compiler switches. – Richard Critten Jun 09 '17 at 10:24
  • Options in this dialog that are shown in bold have been changed through the project settings. Whether the value is the same as the default is no longer visible from that screenshot. This may or may not be the default setting. – IInspectable Jun 09 '17 at 10:47
  • @IInspectable That's not correct. Values in bold are explicitely set in the project settings independent of the value defined elsewhere. That's why you need to choose to remove the value and get a non-bold value. – harper Jun 09 '17 at 10:56
  • 1
    The name was "Generate Debug Info" in previous version of VS (at least VS2013). That was more clear. Since the /DEBUG command line option just generates the .PDB file and don't optimize the output module it's a bad name for the option. – harper Jun 09 '17 at 10:57
  • @harper: Precisely what I said: The value has been explicitly set in the project configuration. There is no indication whether this is the same as the default, or a different one, but it **is** overridden. – IInspectable Jun 09 '17 at 10:59
  • @IInspectable Nope, you wrote about a changed value, not about an overwritten value. – harper Jun 09 '17 at 11:02
  • @harper: Yes, I did. That was poor wording. The remainder of the comment very much clarifies the intention, though. – IInspectable Jun 09 '17 at 11:06
  • [Why would I ever want PDB files for the Release build?](https://stackoverflow.com/questions/5457095/release-generating-pdb-files-why) – Cody Gray - on strike Jun 09 '17 at 11:46

3 Answers3

4

The /DEBUG linker option has two immediate effects: link time as well as the amount of information available through the Program Database Files (.pdb).

  • /DEBUG:FASTLINK reduces link times, but only generates partial .pdb's. Private symbol information is left in the compilation products (libraries and object files). This option should be used, when those compilation products are available (usually when debugging an application that has been built on the local machine).
  • /DEBUG:FULL generates full .pdb's at the expense of (considerably) longer link times. This option is useful when you need to debug an application, where you don't have access to compilation products (libraries and object files). This is commonly used when an application has been deployed, where the .pdb's are stored alongside the source code in the SCM.

It is common to use the following settings:

  • Use /DEBUG:FASTLINK for debug builds. This reduces link times, and the partial .pdb's aren't an issue, because the compilation products with private symbol information are available.
  • Use /DEBUG:FULL for release builds that are about to be deployed. This generates full .pdb's required to debug applications that have been deployed, where the compilation products containing private symbol information are no longer available.
  • Do not use /DEBUG. The meaning of this switch has changed across versions of Visual Studio (defaults to /DEBUG:FULL for VS 2015, and /DEBUG:FASTLINK in VS 2017). Upgrading a project silently changes the interpretation of this linker setting, which may be undesirable.
IInspectable
  • 46,945
  • 8
  • 85
  • 181
3

The problem at hand is where debug information is stored. The linked is provided with source object files, and these come with debug information. That information does not need to go into the executable. There are three options for the linker:

  • Simply ignore debugging information (/DEBUG:NONE)
  • Build a database of all debugging information, as a PDB file (/DEBUG:FULL)
  • Build a database of symbolic links to the object files (/DEBUG:FASTLINK).

Now, the option you see is just /DEBUG. That uses a default, which varies between VS releases. For VS2015, which you use, it means /DEBUG:FULL. You can now debug the EXE with the resulting PDB, even if you don't have the object files.

MSalters
  • 173,980
  • 10
  • 155
  • 350
0

You can keep /DEBUG always enabled. This allows to debug the application without changing the project settings. The presence of the .PDB file doesn't affect the run-time performance. I don't think that generating the .PDB actually increases the time to link the program.

harper
  • 13,345
  • 8
  • 56
  • 105
  • Generating a **full** PDB increases the link time over generating a **partial** PDB, because the linker needs to keep private symbol data around. The effect on link time is [documented](https://learn.microsoft.com/en-us/cpp/build/reference/debug-generate-debug-info) to be around 2x to 4x. – IInspectable Jun 09 '17 at 11:44