Hi I have been using GDB debugger, and I recently find out that when I set up a breakpoint at some popular header file, the GDB debugger takes a long time to process such request.
The GDB command I use is: "break source_file.h:429".
Is there any method to speed up without changing the source code?
Related
We can use following gdb command to set breakpoint in all functions in a file:
(gdb) rbreak file.cpp:.*
Is there a way to achieve the same feature when debugging from VSCode?
I am assuming that you are debugging in VS Code using the GDB debugger (and not the Visual Studio Windows Debugger).
GDB, LLDB, and LLDB-MI Commands (GDB/LLDB) For the C++ (GDB/LLDB) debugging environment, you can execute GDB, LLDB and LLDB-MI commands
directly through the debug console with the -exec command, but be
careful, executing commands directly in the debug console is untested
and might crash VS Code in some cases
quoted from https://code.visualstudio.com/docs/cpp/cpp-debug
as Alan Birtles said in a comment to you question, you should be able to enter the gdb command here
I'm having problems debugging my C++ code. I'm using GDB with QtCreator and when the code stops at a breakpoint and I step over (either using keyboard shortcut, or from the menu) most of the times it goes to an irrelevant file (like memory or algorithm from STL, or some other Qt file)
At the beginning I thought I pressed step into or had some other breakpoint and it stopped there, but I tried it with only setting one breakpoint
Any ideas?
It was suggested it's a duplicate question (Setup GDB with QtCreator) but it's not, because as I said in my case all breakpoints work, the program stops at the correct line, but step over doesn't work, even when I step into and then step out the code doesn't return to the previous line of code
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.
I'm using Eclipse Mars and trying to debug a C++ file. I'm adding a breakpoint to a line, but after a few seconds I get the warning:
Breakpoint installation failed: Interrupt failed.
And the debugger doesn't stop at that point even though I know for sure that the code does reach the line with the breakpoint.
What can be done to solve this issue?
This messages indicates that the source file where you set the breakpoint does not belong to the actual binary you are debugging
The error message says: "interrupt failed". This does not seems to be a problem with matching binary with source file, it is rather a problem with GDB not being able to interrupt the process. My suggestion is to restart the debugger and set the breakpoint before the program actually starts.
I have this error sometimes when I debug a C++ multithreaded program in Eclipse.
Although I hadn't encountered such a problem with Eclipse, my suggestion is to look to Eclipse forum following these links:
https://www.eclipse.org/forums/index.php?t=tree&th=201329#page_top
https://bugs.eclipse.org/bugs/show_bug.cgi?id=331833
Make sure that "Skip All Breakpoints" is not enabled!
skip breakpoints button
I've had this warning on Eclipse TrueStudio Atollic. It didn't hamper at all my debugging. I rebuilt, checked breakpoint properties unsuccesfully. Then I remained in Eclipse ide, closed the project, reopened it and the warning had disappeared.
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.