I've got a simple Hello World project in the Code::Blocks IDE which I'm compiling using the Intel C++ compiler.
I've set the compiler option '/Zi' in the projects Build Settings so I can debug the application with breakpoints. However no breakpoints are ever reached.
It appears that no debugging symbols can be found within the object.
They are correctly reached when I change to use the gcc compiler however.
What am I missing here? Shouldn't this work as is?
[Update]
Seems to work on Linux but not on Windows. I ran the same sort of test a simple project with Intel compiler and the correct compiler option and I could reach breakpoints. Is there some reason Windows would have a problem?
Is there some reason Windows would have a problem?
On UNIX, the debug info is usually completely documented, and often standard (e.g. Linux uses DWARF).
On Windows, Microsoft compilers use .PDB (Program Database) files, which are completely undocumented and proprietary. GDB can't use them.
I don't know what debug info format Intel compiler generates, but chances are that format is only understood by idb.
Effectively then, you can't mix and match GDB with any of the Microsoft or Intel compilers.
Related
I was trying to debug C++ code which I compiled with Intel C++.
I tried very small Test Program. I compiled with "/Zi" option, I see that *.pdb files is generated but gdb does not show any debug symbol. Even I am not able to break at main() function.
In the forum people mentioned about "idb" debugger for intel. But I do not find it in my Installation area. I have Intel composer edition on one machine and Professional Addition on other. Both places I do not find "idb".
Could anyone suggest any method using which I could debug the code which is compiled with Intel C++.
I see that *.pdb files is generated but gdb does not show any debug symbol.
Until very recently, the PDB format was completely undocumented and proprietary.
GDB never supported it, and is somewhat unlikely to do that in the future (most GDB developers aren't interested in Windows, and most Windows developers aren't interested in GDB).
Could anyone suggest any method using which I could debug the code which is compiled with Intel C++.
If Intel did a good job of emitting the PDB info, you should be able to use the standard Windows debuggers: VisualStudio or windbg.
I've debugged using Netbeans with Java before, but I'm stuck trying to debug a C++ project. I go to debug > debug project, and it appears to sort of work but there are never any variables shown. Also sometimes a new tab titled "Dissasembly" pops up and I don't know why.
I'm using Netbeans 8 with Cygwin on Windows 8 (and yes I have gcc/gdb installed and the PATH set up correctly).
Just a guess, might be that your gdb can't "understand" the format of the debugging symbols generated by your gcc.
Check the versions of each and consider updating, or try -ggdb option for gcc.
-ggdb
Produce debugging information for use by GDB. This means to use the most expressive format available (DWARF 2, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible.
I have downloaded and installed the Qt 5.1.0 for Windows 32-bit (MinGW 4.8) from the qt-project downloads page. I have run the installer, and am able to compile and run applications using these libraries and the minGW 4.8 32-bit toolhchain.
However, I have a large application, and when I try to debug it (using the gdb bundled with the minGW toolchain), it takes an insane amount of time to start running, and any interaction with the application takes a long time to complete. Not an annoying amount of time, but an unusable amount of time. Has anyone else had this problem and are there any solutions?
In case this helps, I get lots of output when debugging like this:
Temporarily disabling breakpoints for unloaded shared library "C:\Qt\Qt5.1.0\5.1.0\mingw48_32\plugins\somefolder\somelib.dll"
There is a gdb bug that was introduced at some point between 7.4 and 7.5, which makes it much slower. When debugging QObject classes, the slower becomes awfully slow.
By disabling debugging helper, you improve it, but then you miss a lot of precious information in the Local Variables and Expressions. For instance, you cannot display nicely the contents of QLists, etc...
It seems that either:
buidling gdb from the CVS or
using an older gdb (7.4.1)
solves the issue.
Qt creator has "attempt quick start" in its gdb options. It helps a LOT.
Or you can switch to using MSVC compiler on Windows. That also switches your debugging to CDB instead of GDB and bypasses the problem entirely. You can just install MSVC compiler and plug it into QtCreator instead of mingw if you don't like MS IDE.
P.S. This also gives you readable core dumps which is a godsend.
See the comments on Zeks' answer. There he explains that switching from the MinGW toolchain to the Microsoft toolchain (compiler, debugger) solves the problem completely. Fortunately, Qt Creator supports the Microsoft toolchain so you don't need to switch IDEs.
After I did that, debugger launch time is now 4sec, and on app crash it there is zero delay. It also sped up builds a lot.
For reference, I've described how I've set up my system here.
I have managed to improve the debugging speed significantly after changing several settings:
Made sure the compiler is gcc.exe and not g++.exe in the Qt5.1.0\Tools\mingw48_32\bin folder
Unchecked Use Debugging Helper in the Tools->Options->Debugger->Locals & Expressions menu
Unchecked Stop when qWarning() is called and Stop when qFatal() is called
Assuming I'm using not-Visual Studio, and building at the command line with cl.exe, what debugger should I use?
I tried using gdb.exe from MinGW but it doesn't seem compatible with the debugging symbols that cl.exe outputs (it reports "no debugging symbols found").
I feel like this is a kind of ridiculous question to be asking, but it seems to be literally impossible to find information on MSVC++ that isn't VS-specific.
Right now I'm using an install of Visual Studio 2010 Express just for access to cl.exe, but I do not use it as an IDE.
You should learn WinDBG, it can debug both user-mode and kernel-mode code. As you're referring to GDB, I assume the command line interface of WinDBG won't be a problem for you :)
By the way, WinDBG is the official debugger of the Windows developers, so you can expect it to be supported for a long time.
Use WinDbg. This is an excellent debugging tool, although it might get some time to get into. MinGW won't cut it, as it uses a different symbol format. WinDBG is also part of Windows SDK, that you likely have already installed, so just check if you have it already.
If you have Visual Studios (and I don't think you can get cl.exe
without it), you can still use its debugger. It's a bit wieldy, because
it will insist on creating all sorts of project and solution files
you'll have to delete later, but it does work.
What I've usually done in such cases in the past is to develop using g++
and gdb (preferably under Linux), then port the working code to Windows.
This means that you almost never need the VS debugger (and gdb is far
more powerful than the VS debugger).
I've got a project that I need to get working with 3 compilers (Borland, gnu, and Microsoft). It works on 2/3 and now I just need to get it working with Microsofts. It seems to crash in places where it works fine with the other compilers, so I'm wondering if there is a way to debug with the command line, maybe to get a stack trace or get the line which caused the crash, something similar to gdb with gnu.
(Full disclosure: I work on the Visual Studio team)
If you're using the Microsoft C++ compiler, do you have Visual Studio installed already? If so, you can use the built-in debugger. If not, I would recommend trying Visual C++ 2010 Express for free. It has an excellent native debugger. You can break on first chance exceptions (C++, SEH, Win32 exceptions) and go right to the line where it happened along with the call stack, locals, etc.
Debugging Tools for Windows - an outstanding package of debugging tools that includes the cdb and ntsd console debugger (in addition to the GUI WinDBG debugger).
The package has fantastic docs, can easily be set up to be the 'just in time' debuggers that handle a crash, and works very very nicely with crash dumps.
These are the hardcore debugging tools that Microsoft uses for crash analysis (and more).
Note that Windows comes with a version of ntsd debugger (at least it used to - looks like it's not on my Win7 box outside of the tools package installation), but it's a great idea to get the package anyway so you have the latest tools - and like I said the docs are a wealth of great information.
Yes.
C++ : Building on the Command Line
C# : See Debug-Centric Options of csc.exe.
Well, you are having trouble with the one compiler that tries very hard to crash your program on purpose. It's called "Run-time error checks", the /RTC option compile option. You can turn it off to make it behave like those other ones. Or you could pursue the "something's wrong here" angle. It's well documented in the MSDN Library article for /RTC.
Codeview is an older product which does that, but there's no reason why you couldn't use visual studio to do the same thing.