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.
Related
There is a bug that I would like to fix that only occurs on Windows Server without a GUI running. I have set up a Windows Server 2019 machine on Google Compute Engine that reproduces the bug, and would like to debug it.
Ideally, I would like to use gdb, but seeing as the program was built with Visual Studio 2019, gdb can't read the debugging symbols.
I don't have a Windows machine, so using Visual Studio will be difficult. I could set up a VM, but if there's an in-terminal way to do this that would be preferred.
I did a pretty thorough Google search, but it didn't turn up anything. Is there really no Windows solution for debugging C++ code headlessly?
MS has 2 console debuggers called CDB and NTSD so you don't actually need Visual Studio GUI to do the debugging. In fact there are a lot of debugging environments in Windows from MS beside the usual Visual Studio. Just install them in your Windows Server and control them remotely from your terminal
You can also debug MSVC-compiled code with LLDB since the PDB format has been published long time ago and LLVM on Windows does support it. No idea about current LLDB on Linux though
And since you have the source code, sometimes the old-school printf debugger is the best way to analyze the issue
If you can get a Windows VM it'll be much better to do remote debugging. In fact almost all debuggers support that feature including GDB or LLDB, so even if you don't have the source code you can still run any Windows debugger and step through the instructions instead of high-level code lines from a remote machine
An alternative way is to take a memory dump and debug later. After getting the dump file, just drag it into your VS solution or any debugging tool like WinDbg and then select "Start Debugging". Now you can step through instructions/code lines and examine variables' values, or jump to an arbitrary function's stack frame just as if you're really running the malfunctioning app
There are many ways to dump a process' memory. You can set Windows to automatically save a dump file when your app crashes, or just capture memory snapshots manually during runtime. Comparing 2 snapshots is also useful for detecting leaked memory. For more information on how to do that read
Collecting User-Mode Dumps
Steps to Catch a Simple “Crash Dump” of a Crashing Process
There's also an easy way to take a dump of a live process using task manager (or any other similar tools)
Say I am in IPython (e.g. on the new QT console), and that I call a C++ library that I wrote from it (e.g. using SWIG or Boost.Python). I would like to set a breakpoint in my C++ code and have the ability to interact with my C++ workspace (i.e. my variables when I hit the breakpoint) with IPython (e.g. plot my C++ variables, etc.).
In other words I would like to debug my C++ code from IPython. Is this at all possible? What are some tools I can use for this?
(assuming you are on Linux)
You just need gdb. First set up configuration telling gdb where your source files are by adding this to $HOME/.gdbinit:
directory absolute-path-to-source
Now start gdb python and on the gdb prompt do:
set args /usr/bin/ipython
run
You can't directly do gdb ipython because ipython is a script. Please refer to the gdb documentation from here on.
In general, you won't be able to debug C++ code directly with IPython. What you can do, though, is use a C++ debugger to debug your C++ code.
Essentially, you tell your C++ debugger to execute whatever process you need to use to run your code (this could be IPython itself), and set a breakpoint in your C++ code (your debugger will know to wait for the appropriate DLL to be loaded if it's in a DLL). From there, you are debugging your part of the code that is running in the IPython process.
I am remotely debugging a dll (C++, unmanaged) for Microsoft FSX (I do not know whether this matters). The dll is compiled as "Multi-threaded-dll", since it does not work as "Multi-threaded-dll debug". My dll currently just contains a DllStart and DllStop function, this is standard in FSX.
I general debugging works (it stops at my breakpoints), but somehow the debugger also stops in places where I did not place a breakpoint. First the issue came up in the "NO Source available" flavor. After checking
Suppress "No Source Available" pane in 2010 and
No Source available
the only solution working for me was to install the mentioned extension. Now I do not get the "No source" tab anymore, but debugger still stops somewhere outside my code. I have cleaned all breakpoints as recommended in " Debugger stops when there is no breakpoint VS2010 ".
bglmanx.dll is another dll, also started by FSX. I was thinking, OK, maybe there is some ambiguity about the symbols and have renamed my functions to DllStartFSXM and DllStopFSXM (and hence being unique). No improvement.
Any ideas, hints?
It could be caused by having __asm int 3 or a DebugBreak in the other code?
Perhaps there is some way of disabling these commands or reimplmenting the DebugBreak function?
I'm using Eclipse (Helios SR1) CDT for my C++ development. Eclipse interfaces with GDB for debugging, but I can't figure out how to manually enter commands to GDB while debugging through the Eclipse interface. For example, it would be nice to be able to enter p myVar instead of having to click and scroll through the local variables window.
Note: The only reason I'd like to use the Eclipse interface for debugging is because I like how it shows the code that is being stepped through. So if anyone has an alternative to suggest that would allow me to view the code that's being stepped through, please suggest! (I've used DDD, but I don't especially like it.)
It is actually very simple.
Start debugging (eclipse will switch to Debug Perspective). Then make sure Console View is shown. If it's not show it (Window->Show view...). In that view you will find "Display selected console" icon. Select down arrow next to it an select console named "gdb" (not gdb traces!).
What you enter in this console is forwarded directly to gdb (you can use all gdb commands).
If you are not debugging under Windows, you could try the gdb TUI. It's a little awkward to get used to, and is sometimes buggy, but in general it works fairly well. You can see the code being stepped through in one window while still being able to enter commands.
Assuming your version of gdb was built with the --enable-tui configure option, simply fire up gdb and press C-x C-a to enter the TUI. Then, to make sure you can see the code and command windows, press C-x 2 (for two-window layout)
It's been a while since I've had to use the TUI, but it should work for your requirements.
Currently the gdb console of Eclipse just connects the stdin/stdout between the java gui and the underlying gdb process, hence many gdb shell features are missing, e.g. tab-autocomplete, command history etc.
I want to know if there is an enhanced console for fast gdb interacting. I really like the frequently used gdb commands like "print" and "call" etc. IMHO, "print" command is superiors sometimes than Eclipse "Expression watcher" because it only execute once and the later will be evaluated any time and be crash-prone.
If you think there is no need to use gdb console, then what's you best-practise in terms of gdb UI to eclipse UI transfer.
There doesn't seem to be any gdb-specific plugin, beside the initial gdb integration initiated with Eclipse3.4.
And the current list of gdb bugs doesn't include your missing features.
If you're writing c/++, why not just find the eclipse-generated elf and use gdb via the shell?