Generaly IDEs has option to generate MAP file which shows the locations of the functions and the variables across the memory and the STACK and RAM usages.
Where in Visual Studio Projects we can generate a MAP file and get this information.Especially the Stack and RAM statistics.
Maybe you want to take a look at the documentation.
The linker directive which will create a .map file is just,
/MAP[:filename]
and..
filename: A user-specified name for the mapfile. It replaces the default name.
found under https://msdn.microsoft.com/en-us/library/k7xkk3e2.aspx
This linker directive should be what you were looking for :).
Or better to be found under
Open the project's Property Pages dialog box. For details, see Setting Visual C++ Project Properties.
Click the Linker folder.
Click the Debug property page.
Modify the Generate Map File property.
Related
I want to step into the DevExpress XAF code using the debugger.
I have asked about it here but am having problems spotting what I have done wrong.
VS2019 16.2.2
Dev Express XAF 19.1.5 Winforms project
The break point is in Program.cs
at
winApplication.Start
which is in
DevExpress.ExpressApp.Win.WinApplication
I downloaded the .pdb files and set up the Symbols
I un-checked Tools->Options->Debugging->Enable Just My Code
At the breakpoint Debug->Windows->Modules shows that the Symbol file for mscorlib.dll is loaded.
Exception settings are
[Update]
Lance Li pointed out the cannot find or open the pdb file message
When I select Symbol Load Information it mentions the location is
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\DevExpress.Utils.v19.1\v4.0_19.1.5.0__b88d1754d700e49a\DevExpress.Utils.v19.1.pdb: Cannot find or open the PDB file.
I tried clicking the load all symbols button in the symbols screen but it did not help.
I attempted to locate the pdb but got a message
A matching symbol file was not found in this folder
I tried suspending Resharper and that did not help.
[Update]
I noticed that it is looking for the file in the GAC
I see that there is a copy of mscorlib.pdb in d:\pdb\19.1
Could it be that that somehow re-arranges something to expect to find the Dev Express .pdbs in the GAC?
The source code is on GitHub
[Update]
In the DevExpress question Dennis points out that when he hits F11 Visual Studio asks for a source code path. I think this happened once for me I have selected the default path. Now Visual Studio no longer asks.
I tried re-cloning the application but it did not help.
I tried opening up with VS2017 but that did not help.
[Update]
I installed on to a different computer
then at the break point I received a dialog box to select the source code.
I located the source at
Directory of C:\Program Files (x86)\DevExpress 19.1\Components\Sources\DevExpress.ExpressApp\DevExpress.ExpressApp\DevExpress.Persistent.Base
Then I was able to step through the Dev Express code on the second computer.
Now to figure out how to correct the behaviour on the first computer.
[Update]
I was able to get the Find Source dialog up by the following method.
Run to the break point , then select Debug -> Windows -> Modules.
Then right click an unloaded module and un-check Always Load Automatically.
After that when I ran again I got the dialog allowing me to locate the source.
My problem was that Visual Studio was looking in the wrong place for the source.
Further to that, because it had been told to look in the wrong place automatically then I did not receive a dialog asking me to locate the source.
So as to receive the Find Source Dialog , the trick was to unckeck the Always Load Automatically option.
To get at this option, I ran to the break point and then selected Debug -> Windows -> Modules. Then right clicked an unloaded module and un-checked Always Load Automatically.
A different way could have been to add the correct path to the Solution->Properties->Common Properties-> Directories Containing Source Code
I've exported mbed_blinky project for keil uvision 5 and i want to develop a program for another board, so I need to change the start address of program. I change the start in IROM1 in options for target window but it doesn't work. It must be defined in somewhere but I can't find it. Can anyone help?
My target is LPC1768
In uVision, the linker script (or scatter file as Keil refers to it) is either generated from the target settings that you have tried to change or can be overridden on the linker tab with a "scatter file"; it is possible that the mbed export does not generate a uVision target tab compatible scatter file or requires settings not available in uVision's basic target dialog, so is using a custom scatter file.
On the linker tab, check whether or not the "Use memory layout from target dialog" is checked or not. If you want to use the "Target" tab settings it must be checked, otherwise the file in the "Scatter file" setting on the linker tab is used and you will need to edit that, and check all other settings on teh linker tab are correct for your target..
I've used mbed in Eclipse/GCC and am less familiar with Keil. If you want to change target boards/micro's, you are better off doing a new Export from either the online compiler or from mbed-cli tool with the new target selected. The start address is only one of many things that have to change for a new target. The files required to compile for the new target are all on the disc inside the mbed-os folder, but when you exported the original project, they helpfully excluded unnecessary files from the project items. Files are on the disc, just not part of Keil project setup. You would have to also edit the Device on the options tab and the C/C++ include paths and compiler flags as these relate to specific target. Then you will need to locate the correct linker file and startup file for the new target. Again, it is easier to just export a new project for the new target.
I need to use tcl.h in my C project (VS 2012) for registering function in SQLite. I have downloaded Tcl for windows and installed it. But my project still doesn't recognize when I write #include . What should I do to get access to this header?
Thanks in advance.
Open the project properties and do :
Right click on your project, go to properties, go to C/C++ session. On the field Additional Include Directories, add the path to the header you want, and use the header with "".
After that, you should go to the Linker session. On General, go to the Additional Library directories and add the path to the libs you need to add. Then go to Input and add the lib.
Sometimes you will need to copy a dll to the same folder of your executable. You can do that on Custom Build Step - Post Build Events.
You need to do it for each configuration and platform you want to build - one tip to make it easier is to use those variables $(Configuration) and $(Platform) when you are specifying the paths, and select on the dropdown list of the top of the properties window All configurations and All platforms, so you don't need to do it several times per project.
I've got a Windows minidump (C code) and a corresponding exe file. Unfortunately, I don't have the exact matching .pdb files, but I do have .pdbs that contain the exact same code just built at a different time. In Windbg, I can use:
.symopt+0x40
To tell it to load anything, even mismatched symbol files. This works great in this particular instance, and I'm able to get a proper call stack. I'm just curious as to whether or not Visual Studio has any such feature. We use pretty much every different version of VS here, so it doesn't matter which version it might be in. Thanks.
Try this utility:
ChkMatch utility can be used to check whether an executable and debug information file match. It can also be used to enforce matching between an executable and debug information file, if they are compatible.
For more information about debug information matching and related issues, see this article.
Supported debug information formats: DBG, PDB 2.0, PDB 7.0...
There is no override, but the poster to this question found a way to modify the PDB files to make them match the EXE.
Thanks to one of the comments on the
first answer, I checked out a link to
the pdfs of the book "Undocumented
Windows 2000 Secrets: A Programmers
Cookbook". And the author goes into
great detail about the pdb file
format. As I said before, I had
already loaded the pdb into a hex
editor and flipped some bits around
appearing that I made the
age/signature match, but it didn't
work. Well, after using the utility
from the W2k secrets book to "explode"
the pdb into the included streams, I
found out that they hide another
reference to the age in stream
3!!!!!!! Once I flipped that one as
well, it matched up in windbg.
Not sure if you want to go to this much trouble, but it looks like it can be done. If this is for production support then it could be worth your while.
Visual Studio and Windbg match pdbs by comparing the timestamps in the Executable header with timestamps store in the pdb file. You can view the timestamp by running dumpin /headers .
I haven't used chkmatch but modifying either the exe or pdb to match each other should work fine.
Be aware that this technique may not be enough to debug your binary. John Robbins in his book 'Debugging Windows' (which I can recommend) mentions that he's seen different build results from the identical source tree built at almost identical times.
Always build pdb symbols with your builds (including release builds) and archive them alongside the build products and include the .map file for good measure.
According to this post its possible to use sos windbg commands as well in visual studio. But i am not sure if ".symopt" also falls into this category.
I'm told that in VS2019 (16.7 .. 16.8 ballpark) that they switched to a multi-threaded PDB file generator to speed that up.
A side effect is that sections of the file, being generated on different threads, may end up in a different order in the file.
Bottom line, it is even more important than before that you use the PDB that was built with the EXE and no other.
How does one set the "Description" property of an executable? By this I mean the value displayed when you right-click an executable in Windows Explorer and it shows "Description:" with what seems to be just the name of the executable without the file extension.
I'm running GCC 3.4.5 (mingw-vista special r3) on Windows XP.
I have googled the heck out of this to no avail, but I have a feeling I might have to use a resource file with windres... am I on the right track at least?
I actually have been setting a custom name with -o, but I actually want a different one altogether.
That information is taken from a Version Info resource. Windows executables can contain resource files embedded in them. Normally, with Microsoft Visual Studio, you create a resource script (.rc file), and the Visual Studio resource compiler will compile it into the executable for you. VS also contains a nice visual resource editor for editing the various types of resources (string tables, icons, bitmaps, cursors, menus, dialog boxes, version info, etc.).
With GCC, you'll have to create the resource script yourself. See MSDN for more info on the VERSIONINFO resource type. Once you've created a valid resource script, you can use windres to compile it into an object file (.o). This page has a good example of how to do that. Finally, once you have an object file, you just link it in with the rest of your object files as usual.
Yes, you need a resource file.
For info about writing your own .rc resource file (including your FileDescription field), see: MSDN: VERSIONINFO Resource
To link a resource file using gcc, see: "Setting icons [or any resource for Windows programs with gcc":
The Windows versions of gcc (MinGW, Cygwin) come with a tool called "windres". This will compile resource files into object files for you to include at the linking stage. As a simple example, to compile the file 'chocolate-doom-res.rc':
windres chocolate-doom-res.rc chocolate-doom-res.o
This gives you a '.o' that you can conveniently drop into your build, eg.
gcc other.o files.o etc.o chocolate-doom-res.o -o chocolate-doom.exe