I am working with a checked-out Visual Studio C++ Project originally built in VS 2006. I want to put in breakpoints to see where certain functions are called and better follow the workflow.
I rebuilt the code in Visual Studio 2010 in Release mode, and it builds and runs well. Unfortunately, from some research, I have learned that some of the breakpoints cannot be hit in Release mode and I need to build the code in Debug mode to hit the breakpoints.
However, when I try to build the code in Debug mode, the linker complains about the .lib files having the wrong _ITERATOR_DEBUG_LEVEL. Is there a way that I can change this _ITERATOR_DEBUG_LEVEL in the .libs so I can build it in debug mode? If not, is there any way to hit these breakpoints in Release mode or ReleaseWithDebug mode?
I just saw this article from Hansleman recently:
http://www.hanselman.com/blog/DebugVsReleaseTheBestOfBothWorlds.aspx
It basically says you can compile for optimizations (Release) and debug without recompile (Debug) using a combination of debug settings and an ini file.
You can debug C++ in release mode by configuring the projects Properties Pages as follows:
Under C/C++ node -> General node.
Set "Debug Information Format" to "C7 compatible (/Z7)" or "Program
Database (/Zi)".
Under Linker node -> General node. Set "Enable Incremental Linking" to "No (/INCREMENTAL:NO)".
Under the Linker node -> Debugging node. Set "Generate Debug Info" to "Yes (/DEBUG)".
Under Linker node -> Optimization node. Set "References" to "/OPT:REF"
Under Linker node -> Optimization node. Set "Enable COMDAT Folding" to "/OPT:ICF".
You can now debug and step through the code in your release build application.
Note: When setting the properties make sure you have selected the correct configuration and platform (the combo-boxes at the top of the properties pages)
Related
I have a NDK Project in Visual Studio 2019 which uses several shared libraries.
In the project which contains the android_main function i can set breakpoints and use them without problems. If I set a breakpoint in one of my shared libraries (.so) and start the debugger I get this message:
The breakpoint will not currently be hit. Module containing this breakpoint has not yet loaded or the breakpoint address could not be obtained.
How can I load the missing symbols?
I'm using the platform toolset Clang 5.0
What I tried so far:
With this command I proved that symbols are present:
llvm-nm -D libMySharedLib.so
In the modules window (in debug mode) I can see that symbols are loaded for my .so module.
What I'm guessing is wrong:
With NDK typically such problems show up when the debugging info is being stripped away. There is also an option to disable this behavior which is called "donotstrip" in Android Studio. But I'm on Visual Studio.
Apparently, in Visual Studio, when starting the debugger, the respective shared library (.so) project must be set as "Startup Project". Only the breakpoints of the current Startup Project are reached or those breakpoints that are contained in .cpp files, which in turn are part of the respective Startup Project. This is of course not very comfortable and if someone here knows a better solution, a corresponding comment would be very helpful.
Anyway, if a shared library project is to be launched, the appropriate path and name of the .apk file must be set under "Configuration Properties"->"Debugging"->"Package to Launch".
I was wondering if there is a way to synchronize settings for include and link directories between debug and release configurations for project/solution?
More precisely, is there any way to tell visual studio I would like project properties
C/C++ - > General -> "Additional Include Directories"
Linker -> General -> "Additional Library Directories"
Linker -> Input -> "Additional Dependencies"
to be same for debug and release configuration, or somehow efficiently/automatically forward those settings from one configuration to the other configurations? Perhaps there is any plugin/script for that, since it is only necessary to change few lines in project text file to do what I want?
I'm currently using visual studio 2005, but I think this feature should not depend too much on version of the studio, so please post answers/solutions for any version of visual studio.
Use property sheets: create a property sheet containing the common properties, then include it in each build configuration. Do everything via the Property Manager window; be careful now: any change you want to make to the common properties must be made in the property sheet, not in the project properties!
First let me say that I can remote debug a release build on the remote computer. I set up my release build much like my debug build but I mostly had to make sure the Debug flag was not set. I've dealt with doing this for a while and finally decided to try and figure out why I had to go through this. I should also mention that my remote debugging experience is limited to this project and the C# program uses a C++/CLI (built with /clr) .DLL to mediate to some critical C++ libs. I don't need to debug the underlying C++ libs but I do need to debug the C++/CLI code. (One reason I mention this is I can't link libs in statically while using the /clr flag).
I recently discovered Dependency Walker so I used it to see what was going on. Turns out with the debug flag set, the linker links in MSVCR100D.DLL and MSVCP100D.DLL, when the flag isn't set it uses the files without the "D" suffix. Now normally I might just copy over my versions of those .DLLs to the remote machine but there's a problem. My dev laptop with VS2010 is a 64 bit machine and the target machine is 32 bit. That means the only versions of those DLLs I own are 64 bit. I have installed the remote debugging for VS2010 (I had this same problem under 2008) on the remote machine but it doesn't include the debug versions of these .DLLs either (I'm not sure why but I'm assuming this is by design). So my questions are:
As a registered owner of VS2010 is there a valid source for 32 bit versions of these .DLLs I can put on the remote machine?
Is there a simpler way for me to get Debug support? That is can I change some other setting that just tells VS to not use the debug version of those two DLLs? The advantage here is the DEBUG symbol would be set and any conditional code using it would work.
The debug versions of the CRT DLLs are all available with the standard Visual Studio installation, including the x86 versions even on 64-bit machines.
By default, they're located in the following path:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\Debug_NonRedist
Under that folder, you'll find two additional folders (x64 and x86) that contain the debugging versions of these DLLs for the respective platforms.
But pay special attention to the name of the folder (Debug_NonRedist). That indicates that these debug DLLs are not redistributable. It's certainly OK for a developer who owns a license for VS to use them when testing his/her code on another machine, but they should not be distributed to client machines and used to run your application. (Sounds like from your question that you know this, but it's worth pointing out anyway for future Googlers.)
Alternatively, you can change which version of the CRT DLLs that a Visual Studio project links to for specific project configurations. That means that you can compile a "Debug" version of your application, but tell Visual Studio to link to the full redistributable versions of the CRT.
To do that:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Debug" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to either "Multi-threaded DLL (/MD)" or "Multi-threaded (/MT)".
Notice here that you're just telling Visual Studio not to use the "Debug" variants of each of these options. They still mean the same thing. The first will dynamically link to a DLL, the second will statically link the CRT into your application. Pick the one most appropriate for your case. (I often find it convenient to configure my "Debug" builds to statically link exactly for instances like this.)
This question is for an older version of Visual Studio, but in case anyone comes here for a newer version (as I did), there is built-in support to deploy the debug DLLs that you need in VS 2013 (perhaps earlier). This is an obvious setting, but it can be easy to miss if one is rushing through things (as I was). So maybe this will help somebody.
In the property pages, under Debugging, when Debugger to launch is set to Remote Windows Debugger, in the property list, there is an option called Deploy Visual C++ Debug Runtime Libraries. Simply set that to Yes.
Update -- as requested, this is to clarify which property pages I'm referring to, by way of how to access them: In Solution Explorer, right click the startup project (the one in bold), and click Properties on the context menu. The Property Pages window appears. In the panel on the left side, expand Configuration Properties, and then select Debugging, the second item under Configuration Properties.
Edit to the Update: I got here via notification, and did not see that I could have just said, "See Cody Gray's answer for a picture of the window," to meet the request for clarification. But, there's the how-to anyway in case anyone needs it.
I am working on a project which is in release build. I can't work on debug build for certain reason.
In the Release build, can I instruct Visual Studio to link against debug version of MFC DLLs, so I can step into MFC source code? If yes, how could I do it?
You are voiding the warranty doing this. It seemed to work okay though when I tried it on a sample MFC app. Project + Properties, Linker, Command line is where to get started. First put /VERBOSE in there and rebuild the project to see what .libs get linked right now. You need to use /NODEFAULTLIB to disable the release versions of the .libs and add the debug versions of the .libs. You also need to switch the CRT version, /MTd or /MDd depending on which one you use, Project + Properties, C/C++, Code generation, Runtime library.
Using VS2008 I ended up with these linker settings:
/VERBOSE /NODEFAULTLIB:mfc90u.lib /NODEFAULTLIB:mfcs90u.lib mfc90ud.lib mfcs90ud.lib
A common mistake when configuring the compilation/linking/etc. settings in VC++ 2008 is to set them in Release but not Debug (or vice versa) rather than setting them for "All Configurations". Any suggestions on how to avoid this kind of mistake?
Some beginnings of ideas that I have:
Find a way to make VC++ go to the "All Configurations" settings by default when you open the property pages rather than the active (Release / Debug) settings.
Have a VB script that can be run (inside or outside VC++) to check the project settings and raise any inconsistencies detected.
vb or js script is perfectly ok for the task. Just dont forget to teach it that some settings should differ, such as preprocessor defines, or used runtime libraries.
We recently switched to Qt's build (qmake) tool which is capable of generating both makefiles (used in batch product build) as well as project (.vcproj) files when working on individual projects.
The nice thing about it is that we have enforced all settings one could ever wish for beforehand once for all available build targets (i.e. we have debug, release and non optimized release) and have forgotten about manipulating settings ever since.
You can generate .vsproj files with CMake or Scons or similar cross platform build system.