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.
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 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.
I've been updating my Mac toolchain in order to take advantage of C++11 features and eventually get pretty-print debugging of STL data structures. I used Homebrew to build the gcc 4.7.2 compiler. I've been able to recompile the source of my current project using this new compiler. However all versions of gdb that I've tried have various problems when setting breakpoints, viewing source code or viewing local variables.
The version of gdb that I believe is installed as part of the Xcode command-line tools, version 6.3.50, has trouble displaying various template-based variables. I've also built and tried to use several other gdb versions (7.3.1, 7.4.1 & 7.5.1), but each gdb version has problems that make it difficult to impossible to set breakpoints, view source code and view variables. Specifically, these gdb versions don't know the source file or line number of functions defined in header files, breakpoints can't be set in these header-file functions, and many local variables have been "optimized out".
Has anybody else experienced these problems, and if so have you been able to resolve them? Which versions should I be using in my toolchain in order to avoid these problems?
For the record, my development is on a recent MBP running the latest Mountain Lion updates. My IDE is Eclipse Juno with CDT version 8.1.1. And, yes, I've code signed all versions of gdb that I've built and attempted to use.
Thanks for any input,
Bob
many local variables have been "optimized out".
Is this happening while debugging optimized code? If so, that is expected. You may not have seen this happening before, because older GCC didn't quite optimize that much.
To fix: build your to-be-debugged code with -g -O0 flags.
I'm a whiz with Visual C++, but Linux development is new to me. In Visual Studio, it's easy to trace into any code implemented by the C run time libraries. I just need to make sure the sources are installed and I can step right into any function I'd like -- malloc(), cout::operator<<(), whatever.
I'm trying to develop using Eclipse's C++ package. How can I step into C run time routines there? Since Linux is open-source, how do I step into operating system routines? Seems like it should e possible -- am I missing debug information, source code, or both? Something in my configuration?
I'm using Ubuntu 12.10 at the moment. I'm using g++. I believe I'm using the Eclipse build system as I never imported a makefile project; I just started with a simple "Hello World" project from the C++ project wizard in Eclipse.
After hacking at this a bit:
I've installed the libstdc++6-4.2-dbg package thinking it would be debug symbols for the libstdc library:
sudo apt-get install libstdc++6-4.2-dbg
I've also installed dpkg-dev, since the next step said I needed it:
sudo apt-get install dpkg-dev
I tried installing libc6 sources into a directory under my home:
apt-get source libc6
At this point, trying to step into printf() tells me that printf.c is missing. I can't step into malloc or strlen, which suggests that I don't understand how the C runtime libraries are factored in Linux. How are libc, glib, and libstdc++ different? Which packages do I need?
If I ask Eclipse to open the printf.c file I do have (at ~/eglibc-2.15/stdio-common/printf.c), it doesn't open the file (doesn't adjust the debugging window to show the source) and repaints the window that shows the error message about not being able to find the file. (Can't find a source file at "printf.c" Locate the file or edit the source lookup path to include its location.)
Whilst, as a Kernel developer on Linux, I do agree that using the individual tools separately will be a good thing to learn, and as such Basile's answer is usefuel.
However, the stepping into C runtime libraries should be equally possible with Eclipse. But just because the OS is open source doesn't mean that it supports you clambering around inside it willy nilly - in fact, you CAN NOT step into the OS itself from user-mode code. You nee KGDB (google it), and you definitely need a second computer to attach to the one being debugged, because when you step into the kernel, you will essentially lock up the machine, at the very least in the context you are stepping, but most likely also prevent other work from being done until you get back out from the kernel, so for example, if you step into open(), at some point the entire filesystem may well stop working altogether until you are back out of whatever lock you are holding. This wll certainly upset some software. Note that this is just an example of how things may work unexpectedly when debugging the kernel, not strictly "I've done this and it happened" - I have debugged kernels with debuggers several times, and you do have to be careful with what you do, and you certainly can not run the debugger on the same machine, as the machine STOPS when you are debugging.
Going back to the usermode, which you CAN debug via Eclipse, essentially all you need to do is install the source code for the runtime library you are interested in, and go... Same principle as on Windows with visual studio - except that nearly all software you ever run on a Linux system is available as source code. You may need to recompile some libraries with debugging symbols, and just like in Windows, you need to make sure the debugger knows how to find the source code. Everything else should be handled by the debugger in Eclipse. I spent about three years using Eclipse for both local and remote debugging, and in general, it works. There are quirks in places, but that's the case with almost any debugger.
Good luck.
First, you don't need Eclipse to develop software on Linux. You should better learn to do that with independent tools (command line) like emacs or gedit (as editor), git (version control), make (builder) which runs the gcc or g++ compiler (both gcc & g++ are part of GCC, the Gnu Compiler Collection).
really, you'll learn a lot more by not depending upon Eclipse; it may just hide you the real commands which are doing the job, and you should understand what they really are.
You want to pass the -g -Wall options to GCC. The -g option asks for debug information, and the -Wall options asks for almost all warnings. Improve your code till no warnings are given.
And the operating system is providing syscalls (which are operations provided by the kernel to applications; from the application's point of view, a syscall is atomic so you cannot step into it; however strace may show you all the syscalls done by some execution). If you wanted to step by step inside system libraries like libc you need the debugging variant of it (e.g. some libc6-dbg package). But there is usually no need to dive inside system libraries.
See http://advancedlinuxprogramming.com/
Then, you will use gdb to debug the binary program.
So, step by step instructions inside a terminal:
edit your source files with emacs or gedit
learn how to use GCC: for a single source C++ program compile it with g++ -Wall -g source.cc -o progbin and type ./progbin in your terminal to run it. Only when the program is debugged and satisfactory would you compile it with optimizations (by giving the -O or -O2 flag to gcc or g++)
Use gdb to debug a program (compiled with -g).
for a multi-file C++ program, consider learning how to use make
use a version control system like git
For beginners, I suggest to avoid Eclipse, because it just hides to you what is really happening underneath (Eclipse is simply running other tools like the above commands)
Software development under Linux requires a different mindset than under Windows: you really are using your own loose combination of independent tools, so better to learn a bit each of them.
NB. to step inside "system" functions like malloc (which is above syscalls like mmap) you need the debug variant of the libc package with aptitude install libc6-dbg, and you need to set LD_LIBRARY_PATH to /usr/lib/debug etc...
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).