What is the use of .map files VC++ linker produces when /MAP parameter or "Generate map file" project setting is used? When do I need them and how do I benefit from them?
A nice article on how to use map files for finding crashes.
http://www.codeproject.com/KB/debug/mapfile.aspx
Manually doing all this is very uninteresting.
I am not aware of any tools which can read map file and help in finding the crash location. If anybody knows please update us.
For embedded systems, map files are a lot more useful. (Although you wouldn't be using Visual C++ for that ;)
Things like knowing how close you are to running out of program/data memory, and what location a particular variable resides in, are important.
WinDBG uses .map and .pdb files to help debug crashes, when analysing .hdmp and .mdmp crash dumps.
Basically they map memory address offsets to functions and variables within the .exe (and/or loaded .dlls). Very useful in general if you need to figure out why a customer is upset. Even more useful when they prove it was not your fault.
The most useful way to debug "post-mortem" crashes is using WinDbg (Windows platform). Open it up, and open the crash dump. Then set the source path to point at the code (if you have it), the symbol path to point at your .map and .pdb and the image path to the .exe, and type "!analyse -v" in the command line. Now you have a full stack trace with lines of code and everything. Of course you need to have the correct version of the source code for the version of the exe's and DLLs you are debugging.
It's even better if you have the MS symbol server in the path, and if the full page heap was turned on or adplus was running. With ADPlus in particular you will likely have variable values captured as well.
Some favourite WinDbg resources of mine:
First stop :: http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx
Force load the symbols :: http://www.osronline.com/ShowThread.cfm?link=182377
Useful site :: http://www.dumpanalysis.org/blog/index.php/category/windbg-tips-and-tricks/page/7/
You need them rarely, but they can be handy debugging some problems because they give information on the location of functions and data.
For example:
detailed information on all segments (code, data and other).
link line numbers to code
You can use map files for debugging tools.
Linker maps can be very useful in large projects when you need to track dependencies between compilation units and libraries. Typically, a linker will report a symbol which caused problems, and more often than not, a simple search for this symbol name won't return any results (or will return tons of false positives for symbols like read).
Without a linker map, the only option you have is to analyze all available source files (after preprocessing pass if macros were used, which is typically the case) and hope that you find the relevant spot.
Linker maps usually have a section called "reference by file/symbol" which tells you which object file was required by another object file of your project, and which symbol exactly was referenced.
I was once working on a project which had to be ported on a system without locale support. The linker was reporting "undefined reference to _localeconv_r" errors, which would have been a pain to track down by searching through the sources. Luckily, a GCC linker map file generated with -Map=output.map revealed all problematic functions with a single search.
amap cross-platform GUI tool allows you to examine MAP files produced by the GCC, Visual Studio and some other compilers. You can find out, for example, how much every source file and every external dependency contribute to size of your executable.
Related
Working in Visual Studio 2013 Professional and I have been trying to debug old code from a VC++ 6 Project. When running the scripts, the error :
Error LNK1104: cannot open file 'DFOR.lib' Visual Studio
Come up. I have tried looking into the issue and it seems that the directory needs to be added in the the project properties, however, I have had trouble finding the directory in my computer. It also does not seem to be on my Companies computer I have been using but I have had trouble finding how to obtain it otherwise.
If you could help me find the DF98 directory (which is what others seems to have used) or help me otherwise, I would appreciate it greatly.
A short file name isn't much to go on but a quick search suggests that DFOR.LIB may have been part of Compaq Visual Fortran in the distant past.
I'm not familiar with that product but it seems to have been taken over by Intel at some point. You could try asking your question in the Intel forum for Intel® Visual Fortran Compiler for Windows* or read some of the relevant posts there already.
On a more general note the documentation for LNK1104 offers some discussion of possible causes and solutions to this error.
At this point you should not assume you need to find DFOR.LIB, you need to figure out why the linker is trying to open it.
Unnecessary LIB File
For example, an unnecessary #pragma comment (lib...) statement or erroneous linker command in your build might cause the linker to try and read DFOR.LIB even if it isn't needed to complete linking your code file.
In that case, the solution would be to delete (or comment out) the unnecessary #pragma comment (lib...) statement or remove the DFOR.LIB reference from the linker command and rebuild your project.
In Visual Studio, the likely place to find an unnecessary LIB file reference is in Project Properties | Linker | Input in the "Additional Dependencies" property. When changing this property remember to do so for all configurations and all platforms (not just Debug & Win32). For a make file or other command-based build linker input files are listed one at a time in the linker command without a specific switch.
A second place you might find an unnecessary file reference is the Linker's /DEFAULTLIB command. There is no specific Visual Studio property corresponding to this switch but it can be specified in the Command Line property.
Required LIB File
On the other hand, if the linker is reading DFOR.LIB to resolve some reference then you need to figure out what part of your code is causing DFOR.LIB to be required.
In the simple case your code is directly calling a function implemented in DFOR.LIB which the linker is trying to resolve. The linker's list of unresolved references might help you figure out the function name.
In the less simple case your code might be calling a function in some other library file which in turn calls a function (or functions) in DFOR.LIB.
In both cases the linker /VERBOSE and /FORCE options may help you gather more data.
Once you know which part of your code results in the need to link to DFOR.LIB you can decide what to do about it.
You might rewrite the code to use a different function in some package you do have access to
You might find a more modern (and supported) implementation of that function - in Intel's Visual Fortran implementation for example
You might find a licensed copy of Compaq Visual Fortran (and hope that it still runs on modern systems)
You might find that Visual Fortran is a red herring and that your DFOR.LIB comes from some completely different package
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.
I've taken the "edge" sample file and moved the appropriate source files into the directory, changing #include(s) where needed to account for the directory structure and not being setup with the library and all that. The goal being to make a more portable batch of code to try some things out. I was wondering, given the list of linker errors (lots of undefined this and that.) Would it A, be possible to take the source and include it all in a way that I won't need linking? And if so B, what would be the suggested route to find which source files have the right code to counter all the undefined stuff I get while linking?
I understand this is a general question, but it requires a general answer and I haven't seen anyone answer this here or anywhere else. I would think it's entirely possible though, OpenCV is BSD and all the source to compile it into the library is available, so I would imagine you could skip the linking to an external library step if you had the source for the library in your project code. Thanks a million to whoever can help me out or lead me into the right direction, it's much appreciated.
If your project requires fully open source code, you can do what you want. Of course, to isolate what you need from OpenCV will be a demanding task. To do that, you need to manually locate the files including the missing objects. In MS explorer you search using "inside the file" query, in linux console you can use "find | grep" combo command.
I sometimes move source files(opencv/modules/*/src) locally in my projects to customize some functions. I also keep the linked libraries which compiler puts second in priority and they become inactive but they still exists in their original form occupying some negligible useless MBs.
I've searched on this issue, and found many flavors and ideas but no real solutions. So, donning my asbestos suit and hoping for the best, I'm going to dare ask it again.
I have managed C# code that calls managed C++ code, which in turn calls unmanaged C++ code. The unmanaged C++ code is throwing an exception, and I'd like to be able to debug through it. However, when I try to (explicitly, via the Call Stack) load the symbols, I get the dreaded "The symbol file MyFile.pdb does not match the module" error.
I'm guessing that this is a generic error code being returned, as the files are from the same build. Using the chkmatch tool would seem to confirm that the files do in fact match.
Any help much appreciated...
wTs
Might be worthwhile checking the path of the loaded dll - are you using the one you thought you where?
If you are using incremental builds, you might also need idb files
I had an issue where MSVC just didn't want to see any debug symbols at the time, didn't work out why, but instead worked around the issue using CrashFinder or windbg instead. Perhaps a reboot will get it working again.
You might like to use symstore during your build to ensure all the pdbs are captured more reliably, that way you can debug across multiple builds of a file too.
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.