Update: I posted a comment on John Robbins blog about the. He wrote a response here:
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/06/19/do-pdb-files-affect-performance.aspx
The project I am working on does not build symbols for its release binaries, and I would like to change this.
Some info:
Mostly C++ code base, some C#.
Compiled under VS2k5, will be moving to VS2k8 Team System.
Time critical software.
Must have optimizations enabled.
Source code is provided to customer so full symbols are fine.
What are the best command line switches to generate what I need, and what, if any, performance hits am I going to take?
Also, are there any "Gotchas" to be aware of?
Generating debug symbols (ie PDB files) is just creating an external file that a debugger can reference when looking at your code in memory. It doesn't affect the code that the compiler or linker generate (sort of like generating a .MAP file).
Now if you're talking about defining _DEBUG in a release build, that's a whole different question.
Update: I posted a comment on John Robbins blog about the. He wrote a response here:
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/06/19/do-pdb-files-affect-performance.aspx
I found the following link on microsofts website:
Generating and Deploying Debug Symbols with Microsoft Visual C++ 6.0
This link pertains to Visual C++ 6, but I am assuming these instructions are the same for Visual C++ 8(2005) and 9(2008).
The information it gives is very similar to the link provided by TheBlack but more in-depth.
The /Zi switch in Visual C++ will create a PDB, but this setting also implies additional settings that will make the DLL or EXE larger. Specifically, /Zi implies /DEBUG, which implies /INCREMENTAL, /OPT:NOREF and /OPT:NOICF. The last three make the compiled DLL or EXE bigger, but they can be overridden by specifying /OPT:REF and /OPT:ICF in addition to /Zi. There is no need to override /INCREMENTAL, as /OPT:REF and/or /OPT:ICF will ensure a full, non-incremental link.
Source: Correctly Creating Native C++ Release Build PDBs
I don't know the command line, but you need to set debug symbols both in c++ compiler config (program database) and the linker (generate debug info) in the IDE.
If you find the settings in the project, you can use help to see which command-lines they refer to.
Related
After having regained an interest in C++ recently, I've been fiddling around a bit with it and as I thought I might need to use a DLL some day, I wanted to know how to build and use one by myself in the first place.
As I'm using Visual Studio Code, I can't (and actually don't want to) use the wizardry of the proprietary Visual Studio versions that are doing a lot of magic in the background. My goal in this was to specifically be able to do it manually using MSVC so as to better understand the processes and commands behind it.
So as a first step, I followed the offical MSDN tutorial on creating and using own DLLs, translating the steps on there into MSVC tool commands and to my own surprise, it all went well and now I'm having my DLL lying around and getting used by my sample application.
The next step for me was then to be able to debug that DLL with the debugger jumping right into the source file, but that's where I'm struggling a bit. I am linking the DLL with /DEBUG to create a PDB and also am compiling the consumer application with /Zi to have debugging symbols enabled in there, too.
Debugging the consumer source works as expected, but when trying to jump into a function exported by the DLL, the debugger simply steps over.
These are the commands I am running / steps I am taking (full path up to the workspace replaced with ${ws} to have the lines shorter here):
Compile the library:
cl.exe /EHsc /c /DMATHLIBRARY_EXPORTS /Fo: ${ws}\obj\ ${ws}\src\MathLibrary.cpp
Link it as DLL with debug symbols:
link.exe /DLL /DEBUG /OUT:${ws}\out\MathLibrary.dll ${ws}\obj\MathLibrary.obj
Compile the DLL consumer with debugging symbols
cl.exe /EHsc /Zi /Fo: ${ws}\obj\ /Fe: ${ws}\bin\math_d.exe ${ws}\src\MathClient.cpp ${ws}\out\MathLibrary.lib
Then I copy the MathLibrary.dll and the MathLibrary.pdb from out\ to bin\ (for the executable to be able to load it) and then run it with the results described above. The debug console in VSCode reads
Loaded '${ws}\bin\MathLibrary.dll'. Symbols loaded.
so part of it seems to work, but I'm not sure on what to try next.
I assume I am either missing something in the linking of the DLL or the compilation of the consumer, but I don't know what exactly it is. I have read that the linker requires both, the DLL and its PDB to be available when linking the executable consuming the DLL, but I'm not quite sure what exactly this means.
Do I need to compile and link the executable in separate steps, passing the DDL's PDB to the linker command for it to "incorporate" it into the executable's PDB?
Or am I making false assumptions here and "jumping into the source of a DLL" is simply not possible? If so, how exactly would I debug a DLL's code, especially if it's my own?
What's the correct configuration to make a privately symbolicatable release build in Visual Studio? I want to generate and store a PDB file which would allow me to symbolicate crash dumps of the built executable, but to avoid embedding debug information in the executable itself which would allow an external user to observe symbols, e.g., function and variable names, without the PDB.
I'm used to the DWARF debugging format, which can either be embedded in an executable or be exported to a separate dSYM file, which seems to be the rough equivalent of a PDB; I'm not sure whether or not Visual Studio has the similar option of ever/sometimes embedding the debug information similarly or not in the executable, and if it does, what configuration options I need to turn on to make sure a release build doesn't embed this information.
The /Z7, /Zi, /ZI (Debug Information Format) compiler options allow you to
select the type of debugging information created for your program and whether this information is kept in object (.obj) files or in a program database (PDB).
Both /Zi as well as /ZI store debugging information in a program database. None of the information will be compiled into the final executable image.
Since you plan to use the debugging information for analyzing crash dumps of (presumably) release builds, make sure the /Zo (Enhance Optimized Debugging) compiler option is also enabled.
I am starting to learn DX11 and running into trouble with the effects framework. I know it was released as source and I have to build it, but the output from the build is not what I expected.
According to the research I've done on this question, the output from the build should be
D3DX11EffectsD.lib for debug
D3DX11Effects.lib for release
However, when I look into the 'Effects11\Debug' directory after building the project, I only see a file Effects11.lib (well, an Effects11 Object Library file which I assume is a .lib, I'm new to c++), and the exact same file in 'Effects11\Release'. Whats going on here? I've never used VS 2010 for c++ before now but I think I am building the solution correctly.
Is this a matter of renaming the files or have I done something wrong without realizing it? There really isn't much documentation on building and linking libraries in vs 2010 that I could find. Anybody have any suggestions?
Thanks
If you compiled exactly what you got off the web, then I think it would be just a naming convention problem.
You should try compiling it into your end application and see if it yells about debugging symbols missing.
You can also go into the build settings (it has been a while since I have used visual studio for anything other than C# so I don't know exactly where that menu option would be (I assume right clicking on the project should yield some useful results)...I generally do my C++ stuff on linux) and check to see what the built targets are for debug and release. If it turns out that the names are the same for both, but the build targets (i.e. the folder and a few other options, like including debugging symbols) are different then you should be good and it is just a naming problem.
Also, if the files are the exact same size it is likely that they are the same since the debug file should be at least a bit larger than the release one.
If it turns out that they are the same file, try re-downloading or re-extracting the source and just compiling the project again without any changes and see if that gets any results.
When debugging a C++ Project using Visual Studio 2010, it cannot find the source for crt. When I am trying to go inside one such module, it displays "No Source Available". It also does not provide an option to Browse so that I can help it locate the source location.
Under the Option Solution->Common Properties->Debug Source Files, the proper location to the crt source is updated.
In lack of source level debugging of crt I have to read through the disassemble which is getting difficult.
Can anyone help me figure out what might be going wrong?
Please Note ** I am using an external build system via Visual Studio to build my C++ Project.
With the guidance of Hans here how I narrowed down to the problem.
While the breakpoint was still active, I listed all the Symbol Load information. I realized that msvcr100d.i386.pdb did not match the dll. It actually went all the way down to fetch from the microsoft public symbol store which off course had the symbols stripped off. So that was the root cause of my problem.
And here is a similar problem in social.msdn
You can see the cause of the problem by using Debug + Windows + Modules while you have a break active. Right-click msvcr100d.dll and select "Symbol Load Information" to get info about the .pdb that the debugger uses.
For some reason the Microsoft Symbol Server supplies one that has the source info stripped. It is probably intentional, something to do with service and security patches of the DLL getting out of sync with the source code in vc/crt/scr. You can get a real answer instead of a guess by posting to connect.microsoft.com
A workaround of sorts is to compile your code with /MTd instead of /MDd, if that's possible at all. Project + Properties, C/C++, Code Generation, Runtime Library setting. The debugger will then use the .pdb file in vc/lib. Do keep your eyes on the ball, debug your code instead of the CRT's.
You can find the sources for the CRT in your installation folder, subfolder VC\CRT\SRC.
If they're not there, did you install them when installing VS2010? (not sure whether you can really choose this).
Using visual studio 2008 SP1,
This line:
LINK : debug\XXXXX.exe not found or not built by the last incremental link; performing full link
appears every single time I compile the project, no matter how small a change I make.
What could be the reasons for that?
Old question, but just in case for someone it is still an issue (and it is..).
Incremental link is incompatible with generating manifest file (Proj opts > Linker > Manifest File > Generate Manifest: Yes). Indeed, generating manifest modifies exe/dll so linker has to do full linkage.
There are some workarounds, for more details:
http://chadaustin.me/2009/05/incremental-linking-and-embedded-manifests/
Temporary (and easiest/fastest) solution is to disable manifest generation during development and enable it again in the release stage. Although this disables XP/Vista-style gui for the app (controls look like in "classic mode").
So it turns out that the problem fixes it self if I add /INCREMENTAL to the linker command line. This in spite the fact that the default behavior according to the docs is to enable incremental linking.
Strange.
Really shooting in the dark but,...
Do you move the XXXXX.exe from where it is built to somewhere else? The whole point of an incremental link is to change an existing exe. If there is none, it will be difficult...
Another possible reason is that the file was changed after the build (probably by another tool)...
All the reasons are listed in the help item for /INCREMENTAL:
Additionally, LINK performs a full
link if any of the following
situations occur:
The incremental status (.ilk) file is
missing. (LINK creates a new .ilk file
in preparation for subsequent
incremental linking.)
There is no write permission for the
.ilk file. (LINK ignores the .ilk file
and links nonincrementally.)
The .exe or .dll output file is
missing.
The timestamp of the .ilk, .exe, or
.dll is changed.
A LINK option is changed. Most LINK
options, when changed between builds,
cause a full link.
An object (.obj) file is added or
omitted.
An object that was compiled with the
/Yu /Z7 option is changed.
Download procmon from Microsoft.
Run it, set up a filter so that you are looking for accesses to the path that contains your .exe name.
Do a link.
See what trouble it's having -- does it find it, does it log an error on opening it. Procmon will log every single file open, read, close, etc. If it gets an error, it will log it.
Also make sure it can find the .ilk file -- I think it needs that as well.
(ALso in the dark) One possible reason is that you use a project-wide header referencing the __DATE__ macro. But in that case, you'd see a full recompile as well (do you?)
In my case, I have got this error yesterday.
VS set code generation > runtime Library to Multi-threaded Debug DLL (/MDd) instead of Multi-threaded Debug (/MTd).
If i recreate new project this bad settings happens again. I manually switch to /Mtd, then no error happens.