Iam using gdb version 6.8 on red hat linux.In my gdb forward slash(/) is not working.Whenever I press / key i get error bell.
However it works properly for my friend who uses the same gdb version and our .gdbinit files are same.
Thanks in Advance.
our .gdbinit files are same.
GDB uses the GNU readline library, and that library uses ~/.inputrc to control its behavior.
I am guessing that your .inputrcs are not the same.
Related
My knowledge and experience in programming is still very fresh and basic, so please bear with me.
I want to be able to use C++ on my MacBook (OS 10.9.5 Mavericks) via Eclipse, which I have already been using for Java previously.
So I followed the instructions in Eclipse GDB MacOSX Mavericks
to get GDB, but now I still need the GDB command file (.gdbinit), which I can't find anywhere (I tried which .gdbinit on Terminal to no avail).
Please help me.
.gdbinit is a configuration file. You won't have one unless you've downloaded one or written one separately. It goes in your home directory and just contains a list of commands to run on startup. You don't necessarily need one. See this answer: .gdbinit file missing
However, if you are fairly new to programming, I'd suggest starting with Xcode, Clang and LLDB on the Mac for C++ rather than Eclipse, GCC and GDB. It's far easier to get setup, and well documented.
See:
How do I set up a C++ project in Xcode 4?
I'm working on a relatively old Centos system where I am restricted in the packages I can install. I needed a newer version of gdb, so I built that successfully from source in my home dir. This gdb steps through my code fine, but I am looking for trouble that is manifesting in the C++ allocator (mt_allocator.cc) and this new version of gdb can't step through that code. I can break successfully on a function there:
break '__gnu_cxx::__pool<true>::_M_initialize()'
but when that breakpoint hits and I try to step through the code, gdb tells me:
Single stepping until exit from function _ZN9__gnu_cxx6__poolILb1EE13_M_initializeEv,
which has no line number information.
I tried using the dir command within gdb to add the path to where mt_allocator.cc is, but that had no effect.
What do I need to tell gdb so it can find those files?
Ah, found it. The Centos package manager put the debug files for the STL code at /usr/lib/debug. So:
set debug-file-directory /usr/lib/debug
within gdb gets it done.
I installed XCode 5.1 with clang
I installed gcc 4.8 via homebrew
Installed gdb 7.7.1 via homebrew
Using OSX 10.9.3
I compile my c++ source in eclipse kepler with a Makefile using g++-4.8 and try to debug it but when reaching a breakpoint I can't see any variables just like in this question: GDB says "no symbol table," but nm shows file has debug symbols
I followed the suggestions of #Tom Tromey in the suggestions section of that question to use
set complaints 10000
in gdb and then load the file. This revealed lots of errors during loading. First I saw lots of these:
unhandled stab for dwarf OSO file...unhandled stab for dwarf OSO file...
then lots of these:
During symbol reading, location expression too complex.
During symbol reading, Member function "~clone_impl" (offset 414143) is virtual but the vtable offset is not specified.
and then a whole lot more of these:
During symbol reading, unexpected overlap between:
(A) section `__TEXT.__textcoal_nt' from `<snip>/sourcefilename.o' [0x228, 0x28c)
(B) section `__TEXT.__textcoal_nt' from `<snip>/differentsourcefilename.o' [0x268, 0x2cc).
Will ignore section B.
There are lots of errors where one section is being ignored in favor of another.
I used to think gdb was the culprit but I have found today that if I use llvm-g++ instead, then gdb works as expected. I was overjoyed at finding I could actually debug without using cout statements.
Another similar question: How do I get a homebrewed version of GDB working on Mac OS X?
I would like to fix the problem with g++-4.8 and need help.
Most of the answers I found related to outdated versions of gdb but 7.7.1 is pretty recent and should work based on what others suggested on SO.
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
We're using the Eclipse CDT 5 C++ IDE on Windows to develop a C++ application on a remote AIX host.
Eclipse CDT has the ability to perform remote debugging using gdbserver. Unfortunately, gdbserver is not supported on AIX.
Is anyone familiar with a way to debug remotely using Eclipse CDT without gdbserver? Perhaps using an SSH shell connection to gdb?
finally I got gdb run remotly anyhow now. At the Bug-symbol on the taskbar I took Debug Configurations - GDB Hardware Debugging.
In Main C/C++ Applications I set the full path on the Samba share of the executable (X:\abin\vlmi9506). I also set a linked folder on X:\abin in the project. Then I modified my batch-script in GDB Setup. It's not directly calling gdb in the plink-session but a unix-shell-script, which opens gdb. By this I have the possibility to set some unix environment-variables for the program before doing debug. The call in my batch:
plink.exe prevoax1 -l suttera -pw XXXXX -i /proj/user/dev/suttera/vl/9506/test/vlmi9506ddd.run 20155 dev o m
In the unix script I started gdb with the command line params from eclipse, that I found in my former tryals. The call in the shell command looks like this:
gdb -nw -i mi -cd=$LVarPathExec $LVarPathExec/vlmi9506
Then IBM just gives gdb 6.0 for AIX. I found version 6.8 in the net at http://www.perzl.org/aix/index.php?n=Main.Gdb. Our Admin installed it.
I can now step through the program and watch variables. I even can write gdb-commands directly in the console-view. yabadabadooooooo
Hope that helps to others as well. Can not tell, what was really the winner-action.
But each answer gives more new questions. Now I got 3 of them.
When I start the debug config I have to click restart in the toolbar to come really in the main procedure. Is it possible to come directly in main without restarting?
On AIX our programs are first preprocessed for embedded sql. The preprocessed c-source is put in another directory. When I duble-click the line to set a breakpoint, I get the warning "unresolved breakpoint" and in the gdb-console I see, that the break is set to the preprocessed source which is wrong. Is it possible to set the breakpoints on the right source?
We are using CICS on AIX. With the xldb-Debugger and the CDCN-command of CICS we manage that debugging is started, when we come in our programs. Is it possible to get that remotely (in plink) with gdb-eclipse as well?
I wouldn't normally take a shot in the dark on a question I can't really test the answer to, but since this one has sat around for a day, I'll give it a shot. It seems from looking at:
http://wiki.eclipse.org/TM_and_RSE_FAQ#How_can_I_do_Remote_Debugging_with_CDT.3F
...that even if the CDT has changed since that wiki page was made, you should still be able to change the debug command to:
ssh remotehost gdb
instead of using TM which uses gdbserver. This will probably be slightly slower than the TM remote debugging since that actually uses a local gdb, but on the other hand this way you won't have to NFS or SMB mount your source code to make it available to the local debugger (and if you're on a LAN it probably won't matter anyhow).
There's also a reference TCF implementation for linux, which you may or may not have any luck recompiling for AIX, but it allows for remote debugging if gdbserver is otherwise not available:
http://wiki.eclipse.org/DSDP/TM/TCF_FAQ
tried also to remotly debug an aix-appl with windows eclipse-cdt-gdb.
Got blocked at the end with unix/windows path-problems. Maybe my result can help u a little further - maybe you already got it work. I'm interested in your comment. asked on eclipse news portal- following the answer of martin oberhuber (thanks again) tried dsp dd (also blocked with path problem) and set an request in eclipse bugzilla.
here the link to news:
http://www.eclipse.org/newsportal/article.php?id=406&group=eclipse.dsdp.tm
Here my bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252758
At the moment we still debug localy with xldb but I am trying ddd-gdb at the moment. At least locally gdb is running.