In a presentation by Bungie (A Life on a Bungie Farm) a feature in Visual Studio named 'Source Stamping' is mentioned. I would like to read a bit more information on that subject but finding related information on MSDN proofed to be difficult.
"We also use a feature of Visual Studio called source stamping, which is a linker setting that is used to specify the final location on a server of the version of the source code that was used to build a certain set of binaries. The source is copied up to that location when the build finishes, and since that location is stamped into the pdbs Visual Studio knows that when it is debugging a build off the build site, it should pull the source from that location to use while stepping through the code.
"
What I am looking for is some information that describes the linker setting(s) in question to setup a similar build/debug-environment.
To complement my question. I may have been a bit premature. A part in the presentation that I over-read mentions the exact linker setting /SOURCEMAP. But this appears to be undocumented.
This feature is called Source Server, where the information needed to extract the right source revision is embedded into the PDB using the tools and scripts listed on the Source Server page.
Using this system, as long as you have access to the private (unstripped) PDBs for your project, your debugger can retrieve the original source file from your version control system. Supported systems are Team Foundation Server, Perforce, Visual SourceSafe, CVS, and Subversion.
I don't know the specific details, but the compiler can very probably put some cryptographic quality hash of the source code in the executable.
(Imagine that you'll add in the executable the md5sum -or better- of a source code compiled in).
Related
I have set up a symbol server in VS 2010 according to this:
http://msdn.microsoft.com/en-us/library/vstudio/b8ttk8zy(v=vs.100).aspx
But my goal is to step into the Regex class in the RegularExpressions namespace:
Imports System.Text.RegularExpressions
Module Module1
Sub Main()
Dim matObject As Match = Regex.Match("abc", "a")
End Sub
End Module
I do know that the RegularExpressions symbols in the System.dll Assembly were made public a long time ago because I read an article on it a while back that was excited about it and did a small overview. But I can't find the article.
As it stands, when I "Step Into" my Match function, it doesn't even give me the Step-Over dialog. It just steps over.
Turns out there are multiple issues surrounding this. Part of them include Visual Studio 2008 SP1, but that is hardly a relevant issue in late 2013.
The solution for me was... Don't use a Symbol Server. At least in VS 2010, it forces you to use the "Microsoft Symbol Servers" which, depending on one or two factors, may load from the generic location, or may load from http://referencesource.microsoft.com/symbols.
The problem with both, is that every time I've used those Symbol File Locations, they are stripped PDB's. Though as you might notice in the Subdomain "http://referencesource.microsoft.com/symbols", Reference Source is getting a big closer.
So what I did was navigate to: Download Source, which is at that same subdomain. Since I'm using .NET 4.0, I Downloaded the .NET 4.0 Source Files.
WTF?? So now I have downloaded some junk file named NetFramework.aspx. It just freezes my computer when I open it. What's the point? Well, nobody tells you this, but you have to re-name it to Whatever.msi. It's actually an installer.
Once you run the installer, you have the full symbols somewhere on your machine. YAY AGAIN!!! At that point, you need to make sure your Visual Studio is set up properly.
Make sure your project Framework matches the Framework of your Source you just downloaded. (And/Or Vice Versa)
Make sure "Enable .NET Framework Source Stepping" is enabled.
For me, in my Options > Debugging > Symbols menu, I selected "Only Specified Modules" and I selected nothing there. Also, I un-checked the PDB Locations so nothing was selected.
Sometimes the Platform Target is an issue. Mine is set to AnyCPU, but you may need to experiment?
OKAY!! All set, let's do this... Fail.
Now when you hit F11, it still just steps over the code. Well, if you look at your Modules (While running), HOPEFULLY the symbols for System or mscorlib or whatever your Assembly is says SYMBOLS NOT LOADED. (That's Good).
Why is that good? Because if they're loaded, you can't load them. And typically, if they're loaded, they are loaded from some janky stripped PDB location that gets you nowhere. So you right-click the assembly of choice and Load From Path... and go to wherever you installed those PDBs from the MSI.
Well great... now if you try to step into the .NET Framework code, or if you try to Load the code from the Call-Stack, you just get a missing code error and the option to find the source code is Greyed Out!! Well I thought we HAD The CODE!!!! I JUST LOADED IT.
Let's look back at the Module window. Next to the assembly you're wanting to load, you'll probably notice in the Version that it says something like "built by: RTMGDR" or "RTMRel" or something like that. Well, RTMGDR means the current version of code being used is different from the original. Why is it different? Because a KB Security Update was installed. And since the Code is different from the PDB... you can't step in.
Unfortunately, you can't get the latest PDB. Who knows why... maybe because it's a security update. But what you CAN do... is google your version like so:
"mscorlib.dll" 4.0.30319.xxx site:support.microsoft.com/kb
You do not have to click anything. Just look at the URL of the first result and you'll see the KB number like so:
support.microsoft.com/kb/12345
Open up your Add/Remove programs (Run: appwiz.cpl), and view Installed Updates. You'll VERY Easily find that KB under your Visual Studio group, and can Uninstall it.
Then run Visual Studio again.. and you'll probably see a new RTMGDR with an Older version... Google that, Remove it's KB... Rinse and Repeat.
KEEP TRACK OF THE KB's YOU REMOVE (In Order). So you can later Re-Install them after your Research.
Once you are FINALLY down to Version x.x.xxxx.1 (RTMRel), you run your Visual Studio to the break point... Open your Modules... Load Symbols From Path... Select your PDB's from your MSI... Then.... Step into your .NET Code
FINALLY!!!
Now when you're done, re-install those KB's, but keep all other settings the same for next time. Security is important.
I've added a custom build step to my Visual Studio project files which generates the google protobuf .h/.cc files from the .proto input files. But I've been wondering if it's possible to start a compile only if the content of the proto files has changed?
Is there a way to tell VisualStudio from a custom build step exactly that? What is the optimal way to integrate proto files into a visual studio build solution?
At the moment, at every build the .proto file is updated which then also updates the time stamp of the output .h/.cc files ...which then issues a recompile of everything dependent from that. Is there a better way around it, while still building them directly from visual studio?
Follow these detailed instructions to specify Custom Build Tool.
Considering your proto file resides together with .h/.cpp files in standard project configuration, here are values to be inserted in Custom Build Tool:
Command Line:
path\to\protoc --proto_path=$(ProjectDir) --cpp_out=$(ProjectDir) %(FullPath)
Outputs:
$(ProjectDir)%(Filename).pb.h;$(ProjectDir)%(Filename).pb.cc
Please note usage of item metadata macros, which replaced some of deprecated macros (like $(InputDir) and $(InputName)).
Now Protocol Buffers compiler will be run only when Input file (i.e. %(FullPath)) is newer than "Outputs".
Maybe this helps. Especially look at the post of Igor Zavoychinskiy:
Solution of this nasty problem is actually simple: in outputs sections
you should specify full path(s). This isn't explicitly stated anywhere
but without this checker just fails to find the files and, hence,
assumes they don't exist. For example for protobuffers compiling
outputs section will be like this:
$(InputDir)\$(InputName).pb.cc;$(InputDir)\$(InputName).pb.h
and (maybe?) kmote00:
...
Bottom line: I just had to make sure my "Outputs" entry exactly
matched the Default Value in the (user-defined) "OutputFile" property.
(Thankfully this also obviated the need for a two-pass build, which
was another annoyance I had previously put up with.)
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).
I am a professional working for a software firm.In my past company basically i was working on C & C++ on unix.Now i suddenly shifted to C++ on Windows and i feel like i am in a completely different world.Basically i am working on a very big application which was totally written in C++.To keep it simple ,i dont have the source code .I have the exe of the application and several other dependent files.it is a GUI application(several windows,reports,graphs and huge mathematical calculations are done by this application).Now i finally have the source code of the application which includes some headers,some vcproj files,some dsw files and several other which i dont even understand why the hell are they present.
Now as i C++ programmer my responsibility is to make all the BUGS that the clients identify replicate and fix them.
If its a bug on unix i can simply use the binary and source code and run gdb/dbx and find out the issue in some or other way like adding adding some printf statements.
But given the files i mentioned above.how could istart debugging an application in VC++ in VISUAL STUDIO.
Is it very difficult for a C++ programmer to shift from Unix to Windows.
Is ther any good resource which i could refer for this kind of change where i could grasp things quickly?
given the exe and the source code of the application how can i start debugging a program by running the application in VS C++-(BTW i am using VS 2005)
The main difference is that on Unix, you'll have Makefiles, which you won't find on Windows. Visual Studio organizes your code in projects and solutions, and those project files contain all the information VS needs to compile&link your projects.
If you have a *.sln file, just double click it to open it in VS. Then build the source (usually by pressing F6) and run in debug mode (usually F5).
More details:
A project is a collection of source files that result in 'something', usually a LIB, a DLL or an EXE.
A solution is a collection of projects. Useful when e.g. one project creates a LIB that is used by another project. When you set dependencies between projects, VS will build the projects in the right order.
Extensions used:
*.vcproj : Project file for C/C++ sources
*.vcproj..user : contains which windows are open in the GUI.
Can safely be deleted.
*.sln : Solution file
*.ncb : Intellisense database for a solution. Can safely be deleted.
*.suo : contains which windows are open in the GUI. Can safely be deleted.
*.dsw : Visual Studio 6.0 related file - not used in VS2005. (Replaced by *.sln IIRC)
./Debug/* : folder with all
intermediate files for a Debug build
(can be changed)
./Release/* : folder with all
intermediate files for a Release
build (can be changed)
That's all I can think of at the moment.
If you only have a .DSW file and not a .SLN file, then it means that the project was probably last worked on with VC6 and not one of the later Visual Studio versions.
That's a shame, because there have been lots of changes to the C++ compiler since VC6, and you're probably going to find the project doesn't compile with VS2005 without needing some minor changes to source code.
Do you have a .SLN file - if so, what's the version number at the top of the file (it's a text file)? If you don't have a .SLN file, can you get hold of VC6?
I would always try to get stuff going on an unfamiliar platform with the best matching tools, before I tried to bring it forward to later versions.
I understand your pain; I took the same path a few months ago.
You probably figured it out, but Visual Studio is not the exact alternative of gcc/g++. It embeds a text editor, a debugger, and so on.
Usually, you have two compilation "modes", debug and release. (you can add your own)
When in debug mode, all optimization are disabled and you can execute your program in the debugger, use step by step, add breakpoints, ...
Just start it using the F5 key.
More notes on the additional files:
In the Visual Studio world, .vcproj files represents "projects": a bunch of file that belongs to the same project (source files, headers, resources, ...).
A .dsw (old name for current .sln files I believe) is a "solution" file: a group of one or several projects which can have internal dependencies. Example: you can have in the same solution, a library and a software that depends on it. So that when you compile the whole solution, things are built in the correct order.
First thing you should try is to attach to the process while it's running (Ctr-Alt-P and select the process) if you have the .pdb (debug information) files you should be able to debug the process without re-building it.
If that fails try to un-check the "Require source files to exactly match the original version" option in Tools -> Options -> Debugging.
If that too fails you'll have to build the application again (by opening the .sln file and performing a build) so that the binary matches your source files.
Good luck.
Compile the code with debug info and press f5 (Start Debugging). I don't see where is the problem. On linux is sort of the same.
VS2005 can convert the dsw file for you to a sln file, but you need all of the original VC6 files in order for the conversion to be successful. For debugging please check out following msdn link, I hope this will help you.
http://msdn.microsoft.com/en-us/library/sc65sadd.aspx
Please select hyperlink "Debugging Native Code" for C++ specific.
I am analyzing a .dmp file that was created and I have a call stack which gives me a lot of info. But I'd like to double click on the call stack and have it bring me to the source code.
I can right click on the call stack and select symbol settings.. where I can put the location to the PDB. But there is no option for the source code directory.
The source code directory is unfortunately hard coded into the pdb's however if you know the folders required you can use windows concept of symbolic links, junctions.
I use the tool Junction Link Magic
Read this article about how to set up a Source Server (aka SrcSrv) integration at your site.
I took the time to follow these steps for our codebase, and now we are able to take a .dmp file from any build of our software in the past 6 months... get a stack trace with symbols... and view the exact source code lines in the debugger. Since the steps are integrated into our automated builds, there's very little overhead now.
I did need to write a custom indexer for ClearCase, but they have pre-existing ones for Perforce, TFS, and maybe others.
It is worth noting that the .dmp support in VS2005 is a little shaky.. it's quite a bit more stable in VS2008.
You'll also need to configure Visual Studio to grab the symbols for the MS products from here in addition to your own symbol server:
http://msdl.microsoft.com/download/symbols
That is described in a few places such as on the Debugging Tools for Windows site.
Windbg allows you to setup source paths same as PDB's paths.
After loading the PDB, manually navigate to the source file that matches the current execution location. A PDB contains the path and filename of the source files that built its associated binary, and I suspect the debugger is smart enough to hook things up when it notices that the filename being displayed and the filename associated with with current binary location, match.