This is probably a very basic question. However, I couldn't find any answer by searching the web.
I have a code I need to debug written in C++. For this code, I require to use GCC 4.1.2 in compatibility reasons and I am using GDB 6.6-45. I compiled the code with the -g -Wall -O0 flags to make sure the code can be debugged with GDB.
My problem is that wherever I set the breakpoint, no breakpoints get hit. Also, at the end of the run, I get this message "You can't do that without a process to debug".
By the sound of the message, I think I am missing a very trivial thing. However, I cannot figure out.
Any help would be appreciated.
EDIT:
The platform I am working on is Fedora 8 on VirtualBox. The reason why I am working on VirtualBox is because I wasn't good enough to install older version of GCC (4.1.2) properly without breaking Fedora 20, which is the latest.
As per GDB output, (it's very basic):
[localhost]$ gdb programName
GNU gdb Red Hat Linux (6.6-45.fc8rh)
... typical messages
This GDB was configured as "i386-redhat-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run programName (program arguments here)
...
Program outputs and messages
...
Program exited normally.
You can't do that without a process to debug.
(gdb)
What's shown above is all I have. To set my breakpoints, I did something similar to:
break main
break System::function_name
break System::line_number
and when I run info breakpoints, the breakpoints does show correct cpp file and the line number or the function name, with enabled flag to yes.
If possible try to avoid -O flag and just use -g -Wall only. I have seen some problems with -O flag in older versions. But I'm not sure whether they persist in novel gcc as well. Just give it a try.
Related
I have created and successfully compiled a C++ application for Linux using eclipse. When I debug it from the command line everything works perfect, I can debug just fine.
But I require debugging in eclipse because is more convenient and easy. I configure the debug session and when trying to launch it I get the error:
Error in final launch sequence
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x1fff82e8\nCannot insert breakpoint 2.\nCannot access memory at address 0x80001ea4\n
Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x1fff82e8\nCannot insert breakpoint 2.\nCannot access memory at address 0x80001ea4\n
But I have no idea why I am getting that error, especially because gdb is working fine when I execute it from cmd.
These are my c++ compiler flags in eclipse:
-std=c++98 -O0 -g3 -Wall -c -fmessage-length=0
When creating the project I chose the "Hello world C++ Project" and the "Linux GCC" as the toolchain.
I'm working with the following versions of GDB and Eclipse:
Eclipse Neon.1a Release (4.6.1)
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
The only way I can reproduce this problem is to have address breakpoints enabled. As far as I am concerned this is a bug in CDT, but in the meantime as a workaround remove or disable any address breakpoints from the Breakpoints view.
I have submitted Bug 509894 to track the issue in CDT.
I am currently running OS X Mavericks on this machine, and am compiling a C++ scientific computing application. I would prefer not to convert it to XCode build if I dont have to.
What I am trying to do is to profile the program to find what sections of code are causing it to run slowly. It is a fairly simple build- roughly 15 source files, and the only flags I am adding are: -g -O2 -ftree-vectorize. For example
clang++ MySource.cpp -g -O2 -ftree-vectorize -o MySource.o
I run the program and launch instruments and attach a time profiler to my application. This all works fine. HOWEVER, the hot spot in the code it is identifying makes zero sense, as it is highlighting a line of code that is only called when the class is constructed, and is a fault in construction which logs an error and throws an exception on the following line. No error is being logged, and no exception being thrown, so I am confident this line of code is not actually the one being executed. Am I compiling things properly to be used with instruments? Are there other flags I need to add? I have noticed that it doesnt automatically link to my source code in instruments- I have to go manually find the source code file in question.
I have previously installed GDB to debug C in eclipse, which is working perfectly. I want to do the same now with my cortex m-3, however I can't make a binary object using GDB because it is giving me an error.
I want to make a binary file the following way:
as -mcpu=cortex-m3 -mthumb example1.s -o example1.o
It does not recognize my cortex-m3 and it is giving me the following error:
as: unrecognized option `-mcpu=cortex-m3'
When doing a version check with my GDB it says the following:
This GDB was configured as "x86_64-w64-mingw32".
Is there a way to switch this to arm-none-eabi?
I hope someone can help me.
This isn't really a question about gdb. gdb is the debugger. as is the assembler.
You want to build or get a cross-assembler.
Well, actually it WAS a question about the GDB, because I did not really understand how it worked. I have fixed it now.
I have moved my assembly file to the folder containing my Atollic GDB debugger for ARM processors and did the same command. He interpreted the right MCPU, and the binary file has been made now.
gdb newbie here, so I hope I haven't overlooked something glaringly obvious… (and if I did, maybe a kind soul could point it out anyway? ;)
I'm debugging a GCC C++ application under OS X Lion. As it's quite heavy on STL, I'd really like to use a GDB version with python support (i.e. >=v7) for pretty printing of containers. My application is split up into a backend library (.dylib) that does all the heavy lifting, and a very simple frontend application. All of the sources and binaries are below a common source path, and everything has been compiled with debugging symbols (I tried both -g and -ggdb).
Using the GDB version in XCode (which identifies as "GNU gdb 6.3.50-20050815 (Apple version gdb-1820)"), displaying the source lines of frames in a backtrace works as expected out of the box, no matter whether the respective call happens in the frontend app or the backend library:
(gdb) f 12
#12 0x000000010002ddc5 in FL3D::Resource::createMesh_ (this=0x7fff5fbff7c8, fl3d=#0x7fff5fbff1f8, id=) at /Development/workspace/fl3d/libfl3d/resource.cpp:234
234 std::vector& t = textureIndices_.at(i);
(gdb)
So far so good. GDB 7.5 and 7.4.1, on the other hand, refuse to give me any source lines from the library:
(gdb) f 12
#12 0x000000010002ddc5 in FL3D::Resource::createMesh_(FL3D::FL3DParser&, std::string) ()
from /Development/workspace/fl3d/libfl3d/build/libfl3d.dylib
(gdb)
I'm really confused by the different responses given – gdb6 prints the correct path to the source file and the correct line, while gdb7 gets the function prototype right (supposedly read from the debugging symbols of the .dylib?), but doesn't seem to know anything about the source. Interestingly, though, it DOES show the corresponding source line for calls in the frontend's main() function!
I've already tried manually setting the path to the library's source files with "dir libfl3d", but that doesn't change anything. I also notice that gdb6 says "Reading symbols for shared libraries" a few times when I run the application and gdb7 doesn't – but the symbols don't seem to be the problem, as they seem to be resolved correctly by both versions?
I'm at my wit's end here. Any pointers?
The Apple gdb is displaying the debug information because it knows how to find & parse DWARF on this platform. The gdb version 7 that you're showing is a gdb that doesn't know how to find the DWARF debug information on a Mac OS X system -- that output that you're showing above is what no-debug-info looks like. My guess is that the FSF gdb version 7 support for Mac OS X has not seen a lot of attention, I would be hesitant to recommend using it on this platform.
As bames53 notes, you're far better off using LLDB on Mac OS X at this point. It is the debugger that all of the support work is going in to and Objective-C / C++ container support is rapidly being added to LLDB but not gdb. The gdb provided by Apple is on an end-of-life path and all users will be switched over to LLDB in the future.
Give lldb a try. It's a little different but it's quite good. There is a cheat sheet that a lot of people find useful in the beginning, it shows gdb and lldb command equivalences. http://lldb.llvm.org/lldb-gdb.html
A shared object was built on RedHat Linux and while all the code was compiled with debug, the debugger (gdb) refused to load the symbols and issued an error as in:
...
GNU gdb Fedora (6.8-37.el5)
...
This GDB was configured as "x86_64-redhat-linux-gnu"...
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module libgrokf.so]
With this error, I could not get break points to trigger in any function nor see proper stack trace. I recompiled the entire project but nothing helped. I do know that some time in the past there was no problem in debugging that module.
What is causing this problem?
The problem is that your version of gdb doesn't support the DWARF version used in one of your binaries.
The solution: Update gdb or compile your files using another debug format (DWARF2 works on gdb 6).
I have recently had this problem with freeBSD and nasm, nasm compiling binaries with DWARF3 and the gdb that ships with freeBSD 9.1 doesn't accept it.
I hope this answer helps anyone having a similar problem :P
Debug options for GCC
As it happens, the module that could not debug was mostly built from sources except for one little 'external' object file someextcode.o that was provided by a 3rd party.
In investigating the problem it was found that the someextcode.c was compiled with the -g3 flag which, apparently, places DWARF version of 4 in the compilation unit header. Changing that to -g resolved the problem.
Unfortunately, it appears a problem with a single module can break the debug-ability of an entire shared object (.so) without giving a clear indication of root of the problem.
My issue got resolved by choosing the right gdb version for debugging. Earlier I was using the gdb 7.0... and when I started using the gdb version 7.10, i was able to debug my application.