I'd like to set a set of breakpoints for a certain project to be loaded up when gdb starts. Until now I've been using ~/.gdbinit to hold those breakpoints, however, they are quite tedious to manage when using gdb with another project. Is there a way I can create gdb configurations custom to each project?
You can load any script with -x switch. So, gdb -x projectconfig.gdb yourbinary.
Projectconfig.gdb would contain what you initially had in .gdb_init.
Related
I'm working on a project, where I cannot disclose the details of the code. So, the application is all written in C and C++. Since, a particular file which wanted to debug has a lot of dependencies and exports, I need to debug the whole project. How do I set breakpoints in the code itself so that the debugging would stop at that particular point? I'm using Ubuntu 14.04 (since the project is compatible with this environment) and gdb debugger.
I've tried using
#include <csignal>
// Generate an interrupt
std::raise(SIGINT);
But I keep getting error
error: ‘raise’ is not a member of ‘std’
Even this also didn't work
#include <signal.h>
raise(SIGINT);
Plus the debugging wont stop at that point, so that I could foresee the function at that point. I only want to debug it from console, rather using any IDE.
Since the programfile I want to debug has lot many header files which it imports, I'm unable to make a executable to use gdb. So, while make clean build of my MakeFile I want to debug the particular program file at a particular function. So, for that I want to add breakpoints in the program. I cannot use any GUI for debugging since I should not use.
Have you tried to use GDB Commands?
b lineno - set a break point at line 'lineno'
b srcfile:lineno - set a break point in source file 'srcfile' at line 'lineno'
Read more about debugging with gdb. Be sure to compile all your code with DWARF debug information (so use g++ -Wall -Wextra -g to compile it with GCC).
GDB is extensible and you can define your own gdb commands at startup in your init file, probably .gdbinit and put some initial commands there.
BTW, on Linux, debugging (so the gdb debugger) is using ptrace(2) facilities. And you can use gdb non-interactively on the command line, using scripts.
How do I set breakpoints in the code itself
I don't recommend adding specific C code for breakpoints. So don't do that in your C code. But see also this.
Perhaps you want some backtrace library, like Ian Taylor's libbacktrace ?
I cannot use any GUI for debugging
You don't need to. You'll use gdb on the command line. With an appropriate gdb script, you can even use it non-interactively (e.g. in a Makefile)
I only want to debug it from console, rather using any IDE.
Please realize that IDEs are only glorified source code editors capable of running other external tools (including the GCC compiler and the gdb debugger). You certainly don't need -on Linux- any IDE to run a compiler or a debugger (but IDEs could be convenient, but not necessary, for that), because you can (and should) run your compiler, your debugger, your build automation tool, on the command line.
Since the program file I want to debug has lot many header files which it imports, I'm unable to make a executable
You should fix that first. You need to make an executable. BTW, there is no "import" involved at run time, since header files are relevant only at compile time. Read more about the cpp preprocessor. You probably should invoke GCC (e.g. the g++ compiler, since you have C++ code) with appropriate preprocessor options (sometimes, tools like pkg-config are useful for that). You probably should use some build automation tool such as GNU make (with your Makefile; see this for inspiration) or ninja. You could add ad hoc gdb commands to your build procedure (e.g. with some additional and specific rules and/or recipes in your Makefile).
First, make sure you have compiled with -g. There are other gdb specific flags in gcc. You could add them in too.
Try using ddd, the graphical version of gdb. Great tool if you don't know the gdb command line. Just open up the relevant source file, select the line then click on breakpoint on the toolbar. It will tell you on the console section, what command was actually executed (good way to learn). There is a floating button list with run, next etc. for stepping through your code.
ddd will work on most of the gcc toolchain.
EDIT:
Say your code is made up of 2 files main.cpp and child.cpp. main.cpp contains main(). The executable is called a.out.
To start
ddd a.out &
It will open in main.cpp. To put a breakpoint in child.cpp, click on File/Open Source... and select child.cpp. Then scroll to where you want a breakpoint. Put your cursor on the line, then click on break in the toolbar.
To run, either type run in the gdb window below or click on Run in the floating button dialog.
I'm in the middle of a large debugging project, and every time I start running gdb I have to type b 253.
It would be really nice if I could set my run script so that gdb loads with that breakpoint already set.
To be more explicit: Here are the contents of run.csh:
gdb --args path/to/program arg1 arg2
Can I modify this so that, once I run it, I can just type r and the program breaks on line 253?
Yes. Read documentation of gdb.
You can extend GDB. You can have Canned Sequences of Commands.
You can define or use extensions in Python, in Guile. See also this.
(you might need to recompile GDB itself from source, since sadly not all usual gdb are configured with Guile support)
You can have your .gdbinit file (read about startup files and command files). Btw you might prefer to break in function names, not in line numbers there. Read more about specifying locations.
Actually, many large projects have some .gdbinit (perhaps generated) in their source repository.
Be sure to use a recent version of GDB. The latest one (in March 2018) is GDB 8.1
I have the problem that was discussed several times here: the application runs when started directly from shell and does not run when I try to start it within the debugger in the same shell. Running inside GDB produces the "cannot open shared object" error.
I've read all the posts and did all the suggestions:
I setup LD_LIBRARY_PATH manually and verified that my application runs and ldd -r passes without errors
I setup solib-search-path and solib-absolute-prefix inside GDB to the same value as LD_LIBRARY_PATH and '/' respectively. All the paths are absolute
I ran GDB with strace to see where GDB looks for the required shared libraries and found that it ignores the list of directories from LD_LIBRARY_PATH / solib-search-path
What can I do?
It's GDB 7.11.1 with RHEL 7
I have the problem
If you do, you've done a very poor job of describing what your problem actually is.
I ran GDB with strace to see where GDB looks for the required shared libraries and found that it ignores the list of directories
GDB doesn't look for any shared libraries until it gets notified by the runtime loader that some shared library has been added to the process.
If you didn't attach to a running inferior, then GDB wouldn't look for any libraries, and you've likely arrived at a completely wrong conclusion.
P.S. GDB doesn't use LD_LIBRARY_PATH at all, and setting either solib-search-path or solib-absolute-prefix is usually not needed either (unless you are doing remote debugging, or analyzing a core that came from a different machine).
Update:
the application runs when started directly from shell and does not run when I try to start it within the debugger
In 99.9% of the cases I've seen, this happens because ~/.bashrc or some such resets LD_LIBRARY_PATH inappropriately. GDB starts a new shell to run the application in, and if that (non-interactive) shell resets the environment, the application may behave differently inside vs. outside of GDB.
The correct solution is to make ~/.bashrc (or whatever shell startup file is appropriate for your shell) to do nothing when running non-interactively.
Recently, our development team is starting to use ccache to do faster compile (the compile is done from sandbox /usr/x).
Now, when I compile from my sandbox (/usr/y), and try to set a breakpoint in the code in Eclipse (GDB (DSF) process launcher), it fails to find the file.
Further investigation shows that Eclipse gdb uses the complete path of the file to set a breakpoint (e.g. b /usr/y/untouchedFile.cpp:1234), but the actual path (in the gdb debugger) is actually /usr/x/untouchedFile.cpp.
The only thing that works is to set a breakpoint on the console by typing it, and do a source file mapping when the breakpoint is hit.
I would like to set the breakpoint by clicking on the code line (which used to work before ccache).
I was wondering if there is a way to get around this.
Thanks!
I am trying to debug, with gdb, a plugin to a program. I saw a question earlier that indicated that the directory command in gdb might help. I thought it would help because, when I try to set a breakpoint within the code of the plugin, I get the error that says: "No source file named..." It didn't seem to do anything when I used the directory command with the source path structure. Any ideas? Thanks.
"No source file named..."
GDB will not be able to set a breakpoint until your plugin is actually loaded into the inferior (being debugged) process.
Use (gdb) info shared command to check whether your plugin is already loaded or not.
If it isn't, you can set a "deferred" breakpoint (GDB should be asking you whether you want to set such a breakpoint, assuming you have the default set confirm on setting).
If your plugin is already loaded and visible in info shared output, then you haven't built your plugin with debug info. Rebuild it with -g, and you should be able to set breakpoints in it.