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.
Related
I set a breakpoint in C++ my code and caught it while my program was running.
Then I created a dump file using Task Manager (not Visual Studio itself).
I opened the result dump but didn't find the code where I set the breakpoint. Although I was viewing the same thread where my breakpoint was set, there was completely different stack trace.
What's the reason why this could happen? Am I allowed to create dump by other applications (for example, Task Manager) while debugging in Visual Studio?
An entire book is needed to explain possible reasons. It could be related to ASLR.
Read at least a good operating system textbook.
Then read a good compiler textbook, like the Dragon book.
Windows and Visual Studio are proprietary applications. If you installed Linux and GCC on your laptop (since the Linux kernel and the GCC compiler and the GDB debugger and GNU libc are free software) you could take months to dive into their source code and understand their behavior. On Linux, you could use strace(1) to understand syscall(2), and proc(5) and pmap(1) to understand the address space of processes.
If you have to use Windows, take several weeks to read the documentation of the WinAPI. You could guess what Microsoft programmers did.
If you are allowed to use Linux, read Advanced Linux Programming then study the source code of open source applications (e.g. compilers) interesting to you.
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'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.
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.