I am using layout split within GDB to preview the source code above the assembly code. However, in the bottom panel (the assembly viewer) each instruction address is prefixed with the corresponding C++ function/method signature. The problem is some of my functions have 8/9 arguments and this is causing the signature to be huge, requiring me to open GDB across two monitors, just to see the assembly instructions.
Are there any GDB options to shorten the signature/replace it with something shorter?
gdb --version returns GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1
Related
I am debugging a C++ program. Suppose I am sitting at a breakpoint in gdb and I do bt 50. This will generate the backtrace and show me the call stack with 50 functions that were run in the process of execution reaching where it is now.
Sometimes, I want to quickly examine the code for one of the functions in the backtrace call stack. I know how to do this on Visual Studio. Visual Studio maintains call stack similar to gdb backtrace. On Visual Studio, I can simply double-click a function in the call stack and Visual Studio takes me to the code for that function, even opening the file for me if not opened. Very convenient.
I was wondering if there was a gdb command to show code around a symbol name in backtrace. Currently, the only way I know is to manually find the file and open it in emacs, and then do a search in emacs to take me to the function. Please tell me if there is a better way so it becomes convenient like in Visual Studio.
There are several choices, depending on how you are running gdb.
One simple way is to run gdb inside emacs. You can use M-x gdb (or M-x gud-gdb, which is a bit more old-school) to do this. When running gdb in emacs, simply selecting a frame will cause the source to be visited in emacs, and point will move to the line in question. "Selecting a frame" can be done via the up, down, and frame commands.
If you're running gdb outside of emacs, and want to continue doing this, then there are still options.
One approach is the edit command. Make sure to set your EDITOR environment variable to use emacsclient and set up emacs to respond to this (like M-x server-start).
Then in gdb, select some frame and you can see that frame's source with edit *$pc.
Another approach that some people like is to use the gdb "tui". This is a curses-based interface that shows the source in the terminal.
Yet another approach is to use one of the many gdb GUIs.
This answer describes how you can manipulate the debugging environment when running gdb interactively. The specific suggestion is to use the following command aid in catching a Heisenbug.
(gdb) set disable-randomization off
However, when using gdb from the command-line, you lose a lot of amenities that you would have with a graphical debugging front end (such as nemiver or kdbg). I am using kdbg, which allows me to specify a command-line for use when invoking gdb. Is there a command-line argument that achieves the same results as the interactive command shown above?
I'm debugging some Fortran code with gdb and it keeps stepping through the C code for intrinsic Fortran functions. For example if I try to step past a write call, it jumps into write.c. Is there any way to stop this behaviour? I'm on CentOS 6.3, with gdb 7.2 and gfortran 4.4.
Normally I think "next" should work. But I don't know Fortran, maybe something funny is going on.
Another way is to ensure that you don't have debug info for the intrinsics installed. gdb will automatically skip over functions that don't have debuginfo if you try to "step" into them.
The final way is to upgrade your gdb and use the new "skip" command, which was added exactly for this use case.
I had a problem like this where next wasn't working when I was remote debugging on a cross-compiled target. I finally realized that I had loaded the wrong executable/symbol table using gdb's file command. Hitting next was jumping in to places un-releated to the current line of code. It was doing the best it could given the information I gave it :)
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
Is there a way to set the disassembly flavour like there is in GDB within LLDB so that it spits out Intel style assembly rather than AT&T style?
set disassembly-flavor intel # GDB
but for LLDB.
The exact line to write in your ~/.lldbinit file is
settings set target.x86-disassembly-flavor intel
In the future, you will also be able to tweak how immediate values are displayed with the new settings: target.use-hex-immediates and target.hex-immediates-style.
No, not yet. Intel format disassembly is a feature I'm sure will be implemented eventually, but I don't think anyone is working on it today.
UPDATE: the ability to select the assembly style was added to the top of tree sources (v. http://lldb.llvm.org ) March 1st, 2013 with the -F or --flavor option to disassemble or the target.x86-disassembly-flavor setting in your ~/.lldbinit file. This will be available in future releases of lldb in Xcode.