How can I debug a MinGW EXE with the Microsoft Visual C++ debugger?
You can attach the Visual C++ debugger to any process running on the system (from the Visual C++ menu). But for being able to step through your source code Visual C++ would have to load the symbol file (.pdb if I remember correctly) and I don't think GCC generates those files.
Exists many Visual studio extensions such us: WinGDB, VisualGDB you can find it on the web. It allows you to debug as regular Visual Studio project. These projects are not free but it has full functional 30 days trial. It has some restrictions but it's good enough.
The Problem:
GCC compiler (ie MinGW's gcc) generates debug info with "-g" flag. The debug info is embedded into the generated executable. Windows' compiler, on the other hand, uses a peculiar ".pdb" format to store the debug info. For example, Microsoft Visual Studio's debugger needs not only the executable (.exe), but also its debug info (.pdb) to be available.
The Solution:
There is a small program that can extract .pdb files from executables compiled with gcc.
It is called cv2pdb, available at https://github.com/rainers/cv2pdb.
Download cv2pdb https://github.com/rainers/cv2pdb
Put the cv2pdb.exe somewhere in your path, maybe a custom bin folder, so that it will be accessible through the command line.
Compile your file as usual using MinGW's gcc compiler, with the "-g" flag, so that the debug info is included.
Simply run cv2pdb.exe on your executable.
cv2pdb out.exe
This will generate a out.pdb file in the same directory.
(If you have Microsoft Visual Studio installed) Open the executable directly in Microsoft Visual Studio
devenv out.exe
Note: This command simply opens the executable in Microsoft Visual Studio, without creating a project for it. In effect, you can use whatever text editor + build system you want to build your executable, and then use Visual studio only as a standalone debugger.
Related
How can I debug a .exe from the command line with a .exe generated from cl.exe (Visual Studio C/C++ Compiler)?
If you aren't going to use a proper debugger (such as found with the full version of visual studio or windbg.exe) then your best bet will be old fashioned printed log traces. Add code (when usingh cl.exe usually bracketed by #ifdef _DEBUG/#endif directives) that print messages to the console about your current program state. Using a real debugger is, however, generally much easier.
I want to execute a C++ program in a second machine without any IDE.
I tried to launch the .exe file which is located in the debug folder of the project and to generate a .exe file following this guide.
Both .exe gave me the same errors (launched manually and from a prompt):
The program can’t start because
- VCRUNTIME140D.dll
- MSVCP140D.dll
- VCRUNTIME140_1D.dll
- ucrtbased.dll
is missing from your computer. [...]
So i try to uninstall and reinstall Microsoft Visual C++ Redistributable per Visual Studio 2015, 2017 e 2019 from there, but still the same errors.
What am I missing? How can I run it without install the whole Visual Studio IDE? Thanks for your time.
You need to compile your program to a Release exe file. Compiling your program using Debug will never work on any device unless it has Visual Studio installed on it.
Why this happens?
If you select debugging, before the program runs it loads some DLL files for debugging in visual studio. Now, on other machines visual studio may not be installed, so it couldn't find the DLL files so it will just not start. But Release, it is like its name, when you want to send your program to a friend or use it on another computer or share it on the internet, use Release. But if you are testing bugs and still working on the program, use Debug.
I'm currently following this instruction to build C++ code with tensorflow.
What I want to do is to run the execution (binary) file with Visual Studio's debug mode.
To do this, I think I have to build a binary file via Visual Studio first so that I can set a breakpoint and execute the code line by line.
But problem is that building the code in VS is not that simple because it uses bazel command instead of g++.
Is is possible to build codes using Bazel in Visual Studio?
As of version 0.22.0, there is no plugin support for Visual Studio: see list of supported IDEs and editors.
There is, however, an API to build IDE plugins.
In the meantime, https://github.com/tmandry/lavender has been published. This is a project generator that generates a Visual Studio Solution file and project files given Bazel build files (WORKSPACE, BUILD, etc.). Also debugging works surprisingly well.
I have DLL project (wrote in fortran, C++) compiled with gcc. I would like to debug this DLL but I have to attach to process running on Windows (compiled in Visual Studio). I can't insert breakpoints in Visual Studio to DLL sources.
Please could you help me someone?
Thanks.
In order to set a break point into source code Visual Studio, and really any debugger, has to find a way to map the source lines to address ranges in the executable code. Visual Studio uses the PDB format to create this type of mapping. This file is generated during build time for all languages in Visual Studio. gcc though does not produce this file and hence there is really no way for Visual Studio to map source lines from the file to meaningful values in the generated executable
You could try http://www.wingdb.com/
Apart from that, the easiest way is to rebuild the code using Visual Studio since you have the source. You can get IVF on one month evaluation and use it to generate the DLL and pdb files. If it works and you like IVF, ask your bosses to get you a copy.
Another alternative is to use ddd in a Linux environment. Just create a Linux VM on your Windows machine, rebuild everything for Linux, get ddd and you're away.
I want to use Notepad and invoke the compiler and linker from the command prompt.
No IDE no make , nmake or anything like similar because I want to know the exact syntax required to do the following:
1. create a static library
2. create a dll
Yes, I have browsed the MSDN site but the examples I saw assume one is using the IDE which does a lot of setup behind the scenes
Pls Note: I know how to compile executables using cl also setting up the env using vcvarsall.bat. My question is about compiling static libraries and dlls.
I am using Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86.
Suggestions on to use some other compiler ( gcc, mingw, intel etc.) will not be helpful at the moment.
The C++ compiler is named cl. The compiler options are well-documented on MSDN. The linker is named link. The linker options are also well-documented on MSDN.
You'll need to run vcvarsall.bat to be able to build with the Visual C++ toolchain; this batch file sets up all the required environment variables and such. If you've installed Visual Studio, you should have a shortcut on your Start Menu entitled "Visual Studio Command Prompt." This shortcut will get you a command prompt and run that batch file.
For DLLs, pass the /c flag to cl.exe (which compiles but doesn't link), and pass the /DLL flag to link.exe. Instead of making an executable, it makes a DLL.
For static libraries, use the lib.exe program.
There are multiple approaches, all of which are handily documented in one place:
Visual C++ Concepts: Building a C/C++ Program
Building on the Command Line
Note that the build system completely changed between VC++ 2008 (which you're using) and VC++ 2010 (which is the current release).
A couple of minor things to add.
Personally I wouldn't use Windows batch files.
I would use nmake http://msdn.microsoft.com/en-us/library/dd9y37ha(v=vs.71).aspx building outside of visual studio is nmake's day job and that's the standard way to build visual studio projects for release say on a build machine, rather than in a development environment.
The other thing in nmake's favour is that if cross-platform is important to you then cmake ( http://www.cmake.org/ ) is a brilliant tool for dynamically creating Windows nmake files and non-Windows make files and it comes with ctest for running your unittests and selftests.
Advert over.