What is the difference between dprintf vs break + commands + continue?

Question

For example:

dprintf main,"hello\n"
run

Generates the same output as:

break main
commands
  silent
  printf "hello\n"
  continue
end
run

Is there a significant advantage to using dprintf over commands, e.g. it is considerably faster (if so why?), or has some different functionality?

I imagine that dprinf could be in theory faster as it could in theory compile and inject code with a mechanism analogous to the compile code GDB command.

Or is it mostly a convenience command?

Source

In the 7.9.1 source, breakpoint.c:dprintf_command, which defines dprintf, calls create_breakpoint which is also what break_command calls, so they both seem to use the same underlying mechanism.

The main difference is that dprintf passes the dprintf_breakpoint_ops structure, which has different callbacks and gets initialized at initialize_breakpoint_ops.

dprintf stores list of command strings much like that of commands command, depending on the settings. They are:

• set at update_dprintf_command_list
• which gets called on after a type == bp_dprintf check inside init_breakpoint_sal
• which gets called by create_breakpoint.

When a breakpoint is reached:

• bpstat_stop_status gets called and invokes b->ops->after_condition_true (bs); for the breakpoint reached
• after_condition_true for dprintf is dprintf_after_condition_true
• bpstat_do_actions_1 runs the commands

Answer 1

There are two main differences.

First, dprintf has some additional output modes that can be used to make it work in other ways. See help set dprintf-channel, or the manual, for more information. I think these modes are the reason that dprintf was added as a separate entity; though at the same time they are fairly specialized and unlikely to be of general interest.

More usefully, though, dprintf doesn't interfere with next. If you write a breakpoint and use commands, and then next over such a breakpoint, gdb will forget about the next and act as if you had typed continue. This is a longstanding oddity in the gdb scripting language. dprintf doesn't suffer from this problem. (If you need similar functionality from an ordinary breakpoint, you can do this from Python.)