149

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.

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>
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
casualcoder
  • 4,770
  • 6
  • 29
  • 35

11 Answers11

236

As of GDB 7.2 (2011-08-23) 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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
aculich
  • 14,545
  • 9
  • 64
  • 71
  • 5
    what about if they are from a shared lib load? It answers N by default it seems... `Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]` – bjackfly Jan 23 '14 at 20:54
  • 5
    @bjackfly use `set breakpoint pending on` as described in [how to answer Y in gdb script](http://stackoverflow.com/questions/11356138/how-to-answer-y-in-gdb-script) and [gdb: how to set breakpoints on future shared libraries with a --command flag](http://stackoverflow.com/questions/100444/gdb-how-to-set-breakpoints-on-future-shared-libraries-with-a-command-flag) – aculich Jan 24 '14 at 17:44
  • Note that when you have a breakpoint condition which cannot be resolved at startup (`break g_log if log_level==G_LOG_LEVEL_CRITICAL`), then at least gdb 7.8.1 will stop parsing further commands. If you have additional commands which should be executed for that breakpoint, put the `commands` line before the `condition` line. – Lekensteyn Dec 19 '14 at 12:23
  • @Andry I rolled back your edit to my original blockquote because the text is a verbatim quote from the documentation... I would otherwise agree with your edit if it were my own words instead. – aculich Jan 13 '15 at 07:25
  • @aculich: I see. I would recommend to use the quoting style rather than the code style in any case. – Andry Jan 13 '15 at 09:39
  • The .gdbinit does not work with 'cgdb' so I am fine with the explicit 'save breakpoints /tmp/pointbreak.dbg' and it's opposite 'source /tmp/pointbreak.dbg' – daparic May 05 '17 at 20:00
27

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
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Johannes Schaub - litb
  • 496,577
  • 130
  • 894
  • 1,212
  • One could just as easily use cut-and-paste, but the scripting method seems to be the way to go. – casualcoder Feb 01 '09 at 20:43
  • 1
    i don't think cut-and-paste is easier than just writing a script once, then using it every time again :) after all, that was the very reason you asked this question in the first place, i think :) – Johannes Schaub - litb Feb 01 '09 at 20:50
  • Um, I meant use cut-and-paste instead of the logging method. Scripting is it so far for sure. – casualcoder Feb 01 '09 at 21:56
  • wow! gdb fail! I use it everyday and love many of its features. But lack is just plain dumb. – deft_code Sep 11 '09 at 00:22
  • 4
    This answer is now over 2 years old so it may be obsolete if you are using a newer version of gdb. As of gdb 7.2 you can now use the `save breakpoints` command. – aculich Feb 03 '11 at 01:34
  • This answer is still useful to those of us who need to work with legacy systems. – mMontu Jun 25 '14 at 17:58
11

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Paul Beckingham
  • 14,495
  • 5
  • 33
  • 67
  • 1
    This actually fails to work, I get "warning: save-tracepoints: no tracepoints to save.' This despite breakpoints being set. Using gdb 6.8. – casualcoder Jul 24 '10 at 19:14
  • This works for me. GDB needs the presence of a global .gdbinit in your $HOME/.gdbinit with content 'add-auto-load-safe-path /home/johnny/src/.gdbinit' and thus the src/ folder has also a separate .gdbinit – daparic May 05 '17 at 19:48
9

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Dan Berindei
  • 7,054
  • 3
  • 41
  • 48
6

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.

I also successfully tested it with GDB v6.8 on Ubuntu 9.10 (Karmic Koala).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
  • 1
    Thank you for this snippet! Works great. Successfully tested with GNU gdb 6.3.50-20050815 (Apple version gdb-966) in CarbonEmacs GNU Emacs 22.3.1 (i386-apple-darwin9.6.0, Carbon Version 1.6.0) on Mac OS 10.5.8. – pestophagous Feb 17 '10 at 22:30
5

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
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
badeip
  • 602
  • 8
  • 9
  • Probably makes sense to save these per project, one global break points state file might get messy. – Thaodan Sep 25 '22 at 03:07
4

Perhaps this:

save breakpoints [filename]

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Abel
  • 41
  • 1
  • This has already been covered in [the accepted answer](https://stackoverflow.com/questions/501486/getting-gdb-to-save-a-list-of-breakpoints/3984156#3984156). – Peter Mortensen Dec 01 '19 at 16:50
3

I found the following addition to a previous answer useful to save/load the breakpoints to a specific file.

  • Save breakpoints: bsave {filename}
  • Load breakpoints: bload {filename}

As in the previous answer, 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
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Mark A
  • 33
  • 3
1

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 something. (Toggle back and forth into TUI mode with Ctrl + X, Ctrl + A).

Here's how I work:

  1. start GDB (in normal mode)
  2. enable logging: set logging on - now it should not complain.
  3. toggle back/forth to TUI mode and do GDB stuff
  4. whenever I want to log something (like a huge backtrace dump) - toggle to normal mode
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Magnux
  • 11
  • 1
  • Oh, and if you like using "screen" (like I do) it will get a bit messy, since it uses the same hotkeys. – Magnux Aug 09 '10 at 12:25
0

The problem is that setting a breakpoint is context sensitive. 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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Michael Snyder
  • 5,519
  • 4
  • 28
  • 19
0

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 discovered, that with GDB we can simply set "saved in file" breakpoints by

gdb> source breakpoints.txt

where breakpoints.txt is a file like this:

break main.cpp:25
break engine.cpp:465
break wheel.cpp:57
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
noisy
  • 6,495
  • 10
  • 50
  • 92