Getting gdb to save a list of breakpoints?
-
20-08-2019 - |
Question
OK, info break lists the breakpoints, but not in a format that would work well with reusing them using the --command as in this question. Does gdb have a method for dumping them into a file acceptable for input again? Sometimes in a debugging session, it is necessary to restart gdb after building up a set of breakpoints for testing.
Edit: the .gdbinit file has the same problem as --command. The info break command does not list commands, but rather a table for human consumption.
To elaborate, here is a sample from info break:
(gdb) info break Num Type Disp Enb Address What 1 breakpoint keep y 0x08048517 <foo::bar(void)+7>
Solution
As of gdb 7.2 you can now use the save breakpoints command.
save breakpoints <filename>
Save all current breakpoint definitions to a file suitable for use
in a later debugging session. To read the saved breakpoint
definitions, use the `source' command.
Use source <filename>
to restore the saved breakpoints from the file.
OTHER TIPS
This answer is outdated, gdb now supports saving directly. See this answer.
You can use logging:
(gdb) b main
Breakpoint 1 at 0x8049329
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x08049329 <main+16>
(gdb) set logging file breaks.txt
(gdb) set logging on
Copying output to breaks.txt.
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x08049329 <main+16>
(gdb) q
The file breaks.txt now contains:
Num Type Disp Enb Address What
1 breakpoint keep y 0x08049329 <main+16>
Writing an awk script that transforms that into a format useful for the .gdbinit
or a --command
file is easy. Or you may even make the script emit separate --eval-command
's to the gdb command line...
Adding this small macro to .gdbinit will help you do it:
# call with dump_breaks file.txt
define dump_breaks
set logging file $arg0
set logging redirect on
set logging on
info breakpoints
set logging off
set logging redirect off
end
Put your gdb commands and breakpoints in a .gdbinit file just as you might type them at the gdb> prompt, and gdb will automatically load and run them on startup. This is a per-directory file, so you can have different files for different projects.
An extension to anon's extension to Johannes' answer:
.gdbinit:
define bsave
shell rm -f brestore.txt
set logging file brestore.txt
set logging on
info break
set logging off
# reformat on-the-fly to a valid gdb command file
shell perl -n -e 'print "break $1\n" if /^\d+.+?(\S+)$/g' brestore.txt > brestore.gdb
end
document bsave
store actual breakpoints
end
define brestore
source brestore.gdb
end
document brestore
restore breakpoints saved by bsave
end
With brestore
you can then restore the breakpoints saved with bsave
.
Extension to the answer from Johannes: you could automatically reformat the output of info break
into a valid gdb command file:
.gdbinit:
define bsave
shell rm -f brestore.txt
set logging file brestore.txt
set logging on
info break
set logging off
# reformat on-the-fly to a valid gdb command file
shell perl -n -e 'print "break $1\n" if /^\d+.+?(\S+)$/g' brestore.txt > brestore.gdb
end
document bsave
store actual breakpoints
end
Afterwards you have a valid commandfile in brestore.gdb
This worked for me when the application is compiled with -g
.
EDIT: successfully tested with gdb v6.8 on Ubuntu Karmic.
put the following in ~/.gdbinit to define bsave and brestore as gdb commands to save- and restore breakpoints.
define bsave
save breakpoints ~/.breakpoints
end
define brestore
source ~/.breakpoints
end
warning: Current output protocol does not support redirection
I also get this error/warning in GDB when trying to enable logging in TUI mode, however the logging seems to work when in "non-TUI" mode. So I leave TUI mode whenever I want to log someting. (Toggle back and forth into TUI mode with CTRL-X, CTRL-A).
Here's how I work:
- start GDB (in normal mode)
- enable logging:
set logging on
- now it should not complain. - toggle back/forth to TUI mode and do GDB stuff
- whenver I want to log something (like a huge backtrace dump) - toggle to normal mode
Hope this helps, /M:o)
I know this is an old thread but It came up in my google search to help me do this. I'm new to gdb and found the following addition to the answer above useful to save/load the breakpoints to a specific file.
- Save breakpoints: bsave {filename}
- Load breakpoints: bload {filename}
As above add the following code to the file ~/.gdbinit
#Save breakpoints to a file
define bsave
if $argc != 1
help bsave
else
save breakpoints $arg0
end
end
document bsave
Saves all current defined breakpoints to the defined file in the PWD
Usage: bsave <filename>
end
#Loads breakpoints from a file
define bload
if $argc != 1
help bload
else
source $arg0
end
end
document bload
Loads all breakpoints from the defined file in the PWD
Usage: bload <filename>
end
The problem is that setting a breakpoint is context sensative. What if you have two static functions named foo? If you are already debugging one of the modules that defines foo, then gdb will assume you meant that one. But if you just dump "break foo" into a file and then read that file at start-up, it will not be clear which function foo you mean.
Any other ideas? I have got
warning: Current output protocol does not support redirection
after
set logging on
EDIT:
I know that question is "how to save a list of breakpoints", however I just discover, that with gdb we can simply set "saved in file" breakpoints by
gdb> source breakpoints.txt
where breakpoints.txt is file like this:
break main.cpp:25
break engine.cpp:465
break wheel.cpp:57
The problem is that setting a breakpoint is context sensative. What if you have two static functions named foo? If you are already debugging one of the modules that defines foo, then gdb will assume you meant that one. But if you just dump "break foo" into a file and then read that file at start-up, it will not be clear which function foo you mean.
I don't have the mod points to reply, but what you do is to make your breakpoints explicit, by specifying the source file and line number. If foo() is specified in both foo.c:42, and in bar.c:1337
break foo.c:42
break bar.c:1337
Alternatively, specify an in-source breakpoint that only trigger if the program is running under gdb. See How to detect if the current process is being run by GDB?