I set breakpoints in code in shared libraries and this works well. I have to confirm Make breakpoint pending on future shared library load?. However when I want to save the breakpoints in a file for later use using
save breakpoints filename.bp
I find that I can't use them later with
source filename.bp
the breakpoints don't get set because of this:
Make breakpoint pending on future shared library load?
(y or [n]) [answered N; input not from terminal]
Which automatically answers no and doesn't set the breakpoint. Is there a way to stop gdb asking for confirmation and have it create the breakpoints from the file?
Thanks
First, this is a reported gdb bug.
You can work around this by putting set breakpoint pending on in your .gdbinit. That's what I did.
Related
I have a small work environment related doubt. I am analyzing a binary in LLDB and sometimes, I need to make some changes in the code and re-compile it. And then re-source the new binary into LLDB for further analysis.
Currently, I am doing this
Inside LLDB, use shell <shell-command> to compile the code.
Use file <binary> to reload the binary.
But in this way, I am losing the breakpoints. So, is there any way I can save breakpoints?
Couple of things.
First off, if you are recompiling the binary at the same path you used for your current lldb target, then you don't need to make a new target. lldb will notice the file has changed when you do run read in the new binary & debug information, reset the breakpoints, etc.
But if there are other reasons why you need to make a new target, lldb has breakpoint write and breakpoint read commands that allow you to serialize the breakpoints to a file and then read them back into a new target.
How do I save my current GDB session? and How do I load it again on GDB startup later. There is a brief discussion on .gdbinit in Art of debugging , Chapter 1. But I really don't get the saving part. Is it an autosave?
The .gdbinit file saves some configurations and user-defined commands. When gdb starts, it will try to search .gdbinit file according to some sequences (For the sequences, you can refer https://sourceware.org/gdb/current/onlinedocs/gdb/Mode-Options.html#Mode-Options). For .gdbinit file, you can refer this as an example:https://github.com/gdbinit/Gdbinit/blob/master/gdbinit.
I think you want to store the whole memory dump into the file, then restart gdb, it will reload it. I have search the invoking gdb manual(https://sourceware.org/gdb/current/onlinedocs/gdb/Invoking-GDB.html#Invoking-GDB), but can't find gdb can do it.
Personally, I think this file you request is very similar to core dump file.
I work on program with multiple C++ files. I have run the executable through gdb for debugging segmentation fault. Later, gdb backtrace provided the list of functions before segmentation fault. Later, I tried to set a break point in a file on a particular line-number. (The path specified is absolute path)
(gdb) break /aia/r015/home/sathish/zfs_amr/src/zfslbminterfaced2q9.cpp:100
However, gdb gives the following message:
No source file named /aia/r015/home/sathish/zfs_amr/src/zfslbminterfaced2q9.cpp.
However, this particular does exist in the location. What really the message means?
What really the message means?
The message means that GDB does not know about any source file named /aia/r015/home/sathish/zfs_amr/src/zfslbminterfaced2q9.cpp.
There are multiple reasons this could be the case:
The debug info for this file is missing, either because that file is compiled without -g, or because the debug info was (possibly inadvertantly) stripped later on,
There are some symbolic links in the above path, and GDB knows that file by fully-resolved pathname instead,
The file is actually not linked into the executable at all,
The file part of a shared library, and symbols for that shared library haven't been loaded yet,
Etc.
As Pat suggested, setting breakpoint on zfslbminterfaced2q9.cpp:100 is more likely to work.
If that doesn't work, info sources will tell you which files GDB does know about.
Update:
info sources gives blank
This means that the application doesn't have any debug info at all.
Usually this happens for one of two reasons:
You neglected to specify -g on the link line (some platforms require -g both at compile and link time),
You have a "stray" -s somewhere on your link line (which strips the final executable).
I'm trying to change the LD_LIBRARY_PATH from my C++ program. I'm able to get its value using getenv("LD_LIBRARY_PATH") and set its value using setenv() (and I know that this is working, because when I call getenv("LD_LIBRARY_PATH") again, I get the updated value), but changing its value from inside the program isn't having any effect on it: I still get this error-message:
Failed to Load the shared library file
If I set the value before the executable gets loaded or the application is started, it works fine.
Unfortunately setting LD_LIBRARY_PATH from within a running program will have no effect on it. The reason for this is that LD_LIBRARY_PATH is processed by the dynamic link loader (ld.so), which is the program which starts your program. Your program itself doesn't process LD_LIBRARY_PATH so changing it will have no effect.
I think this may have been asked earlier but i can't find one that satisfied my requirements.
I am debugging(infact trying to understand) a large project by trying to analyze the code flow in various testsuites. But when i try to set breakpoints at some files, i get the error "no source file named filename found".
So my question is:
Can gdb only accept breakpoints for the source files where the code flow enters.?
Can I set breakpoints over entire lines of a file with something like b filename:*
Will a breakpoint at header file be accepted as header files are just appended at compile time?
Any insights are more than welcome.
Edit
I checked these issues with some hello world code and found same results as pointed out in one of the answers.but my issue in the actual project still remains on. I still get the same error even when i can see the edited output of the same line which is not accepted as a breakpoint.
Edit 2
I got it working but don't understand how and why it works..??
(gdb) b /home/neeraj/BTP/trunk/include/header.h:872
No source file named /home/neeraj/BTP/trunk/include/header.h:872
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) b /home/neeraj/BTP/trunk/src/driver.cpp:2
Breakpoint 1 at 0x806c61a: file ../../../trunk/src/driver.cpp, line 2.
(gdb) b /home/neeraj/BTP/trunk/include/header.h:872
Breakpoint 2 at 0x8052fa0: file ../../../trunk/include/header.h:872, line 872.
(gdb)
Any deeper insights..?
No.
No.
Yes.
Make sure you compile with -g (debug) option. Make sure the sourcepaths are set correctly. Use directory, show directories and dir commands to see/set.
The other thing to beware of besides shared libraries is that gdb source file names are relative to the directory where the code was compiled. If you haven't compiled with absolute pathnames, use the dir command to add the compilation directory to the list of places gdb searches for source code.
And a hint: I find I am wildly more productive when I use the Data Display Debugger (DDD) graphical front end to gdb.