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.

Did not see this answer, will check it out.
–
casualcoderOct 3 '11 at 1:31

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]
–
bjackflyJan 23 '14 at 20:54

This answer has now been promoted to the ``accepted'' answer. Times change, software more so.
–
casualcoderFeb 8 '14 at 3:16

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.
–
LekensteynDec 19 '14 at 12:23

One could just as easily use cut-and-paste, but the scripting method seems to be the way to go.
–
casualcoderFeb 1 '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 - litbFeb 1 '09 at 20:50

Um, I meant use cut-and-paste instead of the logging method. Scripting is it so far for sure.
–
casualcoderFeb 1 '09 at 21:56

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.

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).

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.

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 Detect if gdb is running