I'm currently writing a native extension for NodeJS. This is basically a dll that NodeJS will load when you ask for it.
I have VS2012 attached to the Node process. I want to debug into Node's code that does the loading.
I have the .cc and .h files for node, but there are no .pdb files that I can find. How can I set a breakpoint in the Node source?
UPDATE: I DO have a node.lib file. Can that be a replacement for a pdb?
UPDATE 2: Tangential, but for anyone specifically debugging NodeJS, Node actually DOES ship a pdb, available at http://nodejs.org/dist/v0.8.22/node.pdb (replace the version number with whatever version you're looking for).
Without a way to relate actual source code to assembly code, you cannot debug from source code. You need a pdb file.
Think of it that way: any compiler could have generated the code, and even if VS2012 compiler generated the code, there is no way VS could reverse engineer all the code generation phase to know to which source line a specific assembly command belongs. And with inlining and such, it even adds more difficulty to the task.
So any debugger cannot debug without debug symbols, it is just impossible to reverse assembly semantics into a higher level language semantics (you lose structural information during the compilation process). Otherwise, static analysis tools would be so easy to write.
Edit: .lib file does not include debug information either, just the necessary information to link against it. So you're out of luck too.
Related
Our Android application has lot of code written in C/C++ and whenever a crash is reported from production users we get to know the callstack along with the registers state at the time of crash. When the crash doesn't look so evident, registers state and assembly code of crashed functions will be helpful to some extent.
We pack stripped version of libraries into application and we keep unstripped libraries with us so that whenever crash is reported we get to know file and line numbers with help of unstripped libraries (using tools llvm-addr2line, llvm-objdump, llvm-readelf...)
Today we have to manually run llvm-objdump on each symbol against unstripped library to read into symbol's assembly code.
However, to improve developer productivity, we are planning to develop an application for which if we give filename as input the application prints assembly code for all of input file.
Is it possible to print assembly code so
i.e. given a source code file and unstripped library, is it possible to map and print source code and corresponding assembly code?
Similar to godbolt where we can see source code on left pane and corresponding assembly code on right pane.
Thanks.
Suppose that I compiled a dynamic library (Windows DLL and/or Linux shared object file, .so) in debug mode for use by a client application that links to it dynamically. My source code is available to the client application developer.
I need some clarification regarding the following debugging scenario. I've always understood/assumed that in order for the client application to debug into my library
(for e.g. in order for a client application developer to step into my source code while debugging, say using F10 in MS VC++), that they would have to have actually built a local copy of my libraries themselves (with access to my source code), or atleast have local access to my source code without having built it (not sure if that would suffice?).
Am I right on this? In other words, I think it is not merely enough to provide libraries with debugging symbols (PDB files in MS VC++) if the client application is linking dynamically to my application which has itself been built dynamically. Appreciate if anyone can help sort this out for me? How about the situation in Linux? My understanding again is the same as the above. Now if I had compiled a static library (Windows LIB and/or Linux library .a); my understanding is that the they then don't need to have a locally build copy of my source code (I haven't tried this one out yet)?
Is/are my premise(s) correct? If not, can someone kindly provide some detailed explanation preferably with an example? Thanks for your input.
As requested, here's my comment as an answer. Since it only addresses the Windows side of things, anybody who has the Linux (or Mac!) part of the answer is free to edit it in (I've marked this as a community wiki answer).
For VC++, the debug build DLL + matching PDB + matching source is all you need. The hard part is getting them all to match ;-)
Also, it works more smoothly if the source files are at the same path as when the DLL was compiled, but Visual Studio is also perfectly capable of prompting you to browse to the source manually if you have it.
I have more experience with Windows than linux. But I would think the concept is similar.
if the client application is linking dynamically to my application which has itself been built dynamically.
I'm not quite sure if I understand "building dynamically". You might be confused with the dynamic aspect of dll? dll is linked at runtime (not build time) to allow a part of component to be deployed without a full app. For example, an app on Windows that rely on a dll provided by the OS are not impacted when Windows updates that dll as long as the interface is maintained. The only difference between a dll and exe is that dll's entry function is dllmain as opposed to main in exe.
(The only "dynamic build" concept I can think of is building templated classes. But I don't think that's what you mean here.)
Hence, debugging a .dll isn't different from debugging a .exe, it's just that .dll is a separate binary file from the executable. All the source code provide is allowing debugger to align the stepping with lines in source code. When source code is not available, then debugger can still step through assembly code with symbols.
When situation doesn't allow, then developers who are good at reading assembly code can do debugging with only symbols and no source code.
You can usually build a binary with optimized option, then compiler might optimize the assembly code so much that source code alignment in the debugger might not be possible. This usually happens with released code. In those cases when you step through the code, you sometimes see the line or condition jumps that are seemingly different from what you would expect. There is the same on .exe, .exe with libs, or .dll. This is probably why you thought it is always necessary to build your own binary to debug dlls?
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've noticed that when generating a new C++ project using MS Visual Studio 2008, the Release build contains debugging symbols - specifically the following settings are enabled:
The C++/General/Debug Information Format is set to Program Database.
The Linker/Debugging/Generate Debug Info setting is set to Yes.
I have never noticed this on earlier releases of Visual Studio.
So, other than generating a larger EXE file, is there any downside to leaving these settings enabled?
We have turned on those settings in our commercial releases for years now with no apparent downside. The upsides are enormous,though.
We have integrated a crash dump packager that packages the dump along with some other information and emails it (with the user's consent) to a company inbox. This has helped us find problems that would have taken us forever to reproduce and find otherwise.
Although it's slightly off topic, here's a link to an excellent contribution someone made that gives you an easy way to include a crash reporter to a C++/Windows app:
http://www.codeproject.com/KB/debug/crash_report.aspx
Note: It would be wise, though, not to include the PDB file with your release. That said, you must keep the PDB file that matches your released version so that you can correctly debug the problem in the future. If a PDB file is used that wasn't built with the same code that built the exe, the stack you see when you try to debug the dmp will be wrong.
They're turned on by default because:
If you don't create them now, you can't create them later.
You need them.
Enabling debug info in Visual C++ causes a small entry to be added to the binary header, identifying the PDB for this binary. It's too small to be of any size concern, and doesn't contain any useful secrets that you might be concerned about sharing.
(The header entry is labeled RSDS: who can guess why?)
Of course, those PDBs will use more disk space on your build machine / in your backups. Deal with it. You need those PDBs when it comes time to debug something.
Well, you might deliver this debug information and someone might use it to disassemble your code. For some fearful people this alone might be a reason not to leave it this way.
Personally, I think sometimes it's helpful to have debug information available for the release version - this way it is far easier to analyse a crashdump, that will be stored by Dr. Watson in case of application crashes.
I did find some really obscure bugs this way.
Having these options on do not necessarily make your executables bigger. Debug information is stored in a separate file, with the extension PDB. Having debug information available is never a bad idea, unless you're really really short on free storage space.
Perhaps that's why they're on by default: they don't harm your executables. Release builds do use optimizations such as function inlining and generating optimized code, which makes it harder to step through, while Debug builds have these options turned off.
No downside here.
Dave
Add the /Zi switch does make a larger .exe file in addition to the PDB. However you can seperately link with /OPT:REF to keep the .exe file size to a minimum.
The .exe will be slightly larger due to a reference to the .pdb file (i.e., an extra path). That's about it.
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.