I have a VS 2008 C++ project which uses a third-party library (Open Scene Graph).
When i start debugging the project, each time a function from this external library is called, the debugger just jumps over it, because (obviously) the debugger has no .cpp files where to look up the code. It only jumps into header files which are linked to my project because those files exist and their location is known. So, i can only see what's going on in those small inline functions, but not in the bigger functions whose implementation is in .cpp files which i don't have.
I need is to somehow step thru the source code of these third-party dlls/libs the same way I do with my own code.
I downloaded the the whole source code of that library and compiled it on my machine. Now i have the dlls and libs, and the .pdb files, and the .cpp files, too. But how exactly do I tell Visual Studio the locations of the .cpp files of the third-party library, so that it knows, that when i want to step into a function coming from a .dll or a .lib it opens the corresponding .cpp file (even though it's not in my project and is located is a completely different folder)?
Is this at all possible?
I tried copying the .libs, the .dlls (debug versions), .pdbs both to the locations which my Project uses and "Additional Library Directories" and to the project's folder but this must be not enough.
Add the dir with the PDB files to Tools -> Options -> Debugging -> Symbols.
Related
I did the following experiment: I created a statically linked C++ library solution MyLibrary (I took the code from the MSDN example: https://msdn.microsoft.com/en-us/library/ms235627.aspx.) and built it. Then I created another C++ solution MyConsoleApp, using the console application template in Visual Studio (2017). I copied the MyLibrary.lib file to the root of MyConsoleApp project and added MyLibrary.lib to Linker -> Input -> Additional Dependencies (also had to copy over the headers too of course). What I didn't do was to copy over the MyLibrary.pdb file.
I would've expected to get a linker warning about the missing .pdb file but this was not the case. Then I moved only MyConsoleApp to another machine and tried to build it again, this time getting a missing .pdb linker warning. It seems that Visual Studio is storing the .pdb files when building a solution somewhere on the machine and is able to use those .pdb files when linking other solutions on the same machine.
I would like to be able to disable this behaviour or to be able to remove the cached .pdbs so that I could be sure that when sharing work with other developers they won't get warnings that I'm not getting on my own machine.
Visual Studio doesn't cache the .pdb file. What happens here is that the absolute path to the original .pdb file is stored in the build outputs (.exe, .dll or .obj files) and Visual Studio is able to took it up based on that.
Check this answer for a way to prevent that: Remove PDB references from released file.
The solution consists of 3 projects:
C# application which depends on...
CLR C++ library which in turn depends on...
C++ library
I can debug first two, but not the last one ("No symbols have been loaded for this document"). I am in debug mode (all 3), pdb files were created.
The pdb files for both C++ libraries are created in solution\debug directory. .pdb file for CLR library is also copied to bin\debug directory of the C# project, but not .pdb for the last one. So I copied it there manually, but it didn't help.
So how to debug library which is dependency of the dependency?
I restarted VS, as well as computer, I rebuilt solution too.
There seem to be two paths containing Microsoft Visual Studio runtime source files:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\crt\src
and
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include
Some files appear in both directories, but have different sizes. I looked at one file in particular and it had the same method defined in both files.
So my question is, what is the difference in usage for the two paths? I would like to know when I am debugging (I dont mean debug mode) in Visual Studio, which file is the code on the screen?
The include directory has all of the public headers. These are headers that you can include in your code, like <stdio.h> and <type_traits>, plus implementation headers required by those headers.
The crt\src directory contains the CRT sources, including most of the .asm, .c, and .cpp files used to build the CRT. This directory also has a copy of many of the CRT headers, and in some cases these headers are different from what are in the include directory. This is purely an artifact of how the CRT was built.
When debugging into inline code defined in the CRT headers, the debugger should always pick the right header. If both directories contain the same copy of a header, then the debugger will just pick one and since the headers are the same it doesn't matter which one it picks. If the headers are different, then which header the debugger picks depends on the object into which the inline function was compiled. If the object is part of the CRT, you'll step into the header from crt\src; if the object is from one of your source files, you'll step into the header from include. Basically, the debugger should always be able to find the correct copy of the header.
We've greatly simplified this in the Visual Studio "14" CTP. There are no longer any public headers in the crt\src directory, and the headers that are shipped in the include directory are the same ones that were used to build the CRT.
The CRT sits at the bottom of the Visual C++ libraries stack: the rest of the libraries depend on it and practically all native modules depend on it as well. It contains two kinds of stuff: (1) the C Standard Library and various extensions, and (2) runtime functionality required for things like process startup and exception handling. Because the CRT sits at the bottom of the stack, it is the logical place to start the process of stabilizing the libraries.
From The Great C Runtime (CRT) Refactoring by James McNellis:
(1) We ship most of the sources for the CRT with Visual Studio; you can find them in the Visual Studio installation directory under VC\crt\src.
(2) In Visual Studio 2013 there are 6,830 #if, #ifdef, #ifndef, #elif, and #else directives in the sources that we ship with the product; in the Visual Studio "14" CTP there are 1,656. These numbers do not include directives in headers and they do include the STL source files which are largely untouched by this refactoring effort, so this isn't a perfect measurement, but it's indicative of the amount of cleanup that's been done.
I have included a dll file into my project. I reference it from a library folder where also resides dll's pdb file. When I compile I see both dll and pdb copied to main project's bin folder. On small projects this works wonderfully and I can debug into the dll with no problems. Sometimes, however, in larger projects, VS keeps asking for specific cs files even though their pdb file is included in the projects bin folder. That's ok if I can find those cs files, but it's annoying.
Why is Visual Studio sometimes asking for cs files and sometimes not?
It tries its best given the information it has, but sometimes that information is incomplete. When its ready to give up, it gives you the opportunity to provide the file, just in case you know better.
PDBs generally store the path to the file, as it was when msbuild was invoked to build the DLL. If the paths have changed (e.g. you're on a different machine to where the DLL was built, or just that files on the file system have moved) then the path information doesn't do it much good.
There is a process called source indexing that can embed enough information into the PDBs so that visual studio can re-locate the source files in your source control system (so that you get exactly the correct file as it was at the time of the build) but this is usually an extra step that has to be performed to modify the PDBs after the build has occurred.
Try this (from MSDN Forum)
Tools -> Options -> Debugging -> Symbols -> Empty Symbol Cache (button)
then
Tools -> Options -> Debugging General-> Enable Just My Code (checkbox)
and start debugging again. This should solve the problem if it was initiated by accidental third party components debug symbols that doesn't contains sources but storye only file paths.
Is there a way to update the PDB file with the new source location ? I have a project which links to some libraries which are built on another machine and are debug build with the PDB file. I cannot put a breakpoint in the files which are compiled in the libs. These libs take more than 4 hours to build so I dont want to buid them on my machine. Is there a way where i can make the compiler use the new source paths. I am using VS 2005 pro c++.
Thanks
Amit
Instead of modifying the .pdb files to adjust to where you have your source, you should be able to make the debugger see the new source path. Look here for instructions on doing this in Visual Studio, and here for instructions on doing this in WinDbg.
Another this StackOverflow question: Best Visual Studio 2008 Debugging Tutorial.
Is the debugger picking up the .pdb files from the wrong location? Do you have a copy of the .pdb files that match the binaries (i.e. .exe, .dll) that you are executing? Keep in mind that the .pdb files can only be used if they were created at the same time as the exact binaries you are executing.
Try the following:
Rename the (stale) .pdb file that the debugger wants to load, so the debugger will no longer try to pick it up.
Go to Tools->Options->Debugging->Symbols and add the symbol file (.pdb) location to the list.
If the debugger is already attached, right click on the module in the "Modules" list and click "Load symbols". This will re-load the symbols from the path you entered.
Also, if you know the code is exactly the same, but your .pdb file doesn't match the binaries you are using because they were created during different builds, try un-checking the following checkbox:
Tools->Options->Debugging->Require source files to exactly match the original version