Gdb dprintf与break+；命令+；继续？

例如：

dprintf main,"hello\n"
run

生成与以下内容相同的输出：

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

使用

dprintf

是否比使用

命令

有明显的优势，例如速度要快得多（如果是，原因是什么？），或者具有一些不同的功能

我认为dprinf在理论上可以更快，因为它可以在理论上编译和注入带有机制的代码

或者它主要是一个方便的命令

来源

在7.9.1源代码中，

breakpoint.c:dprintf_命令

，它定义了

dprintf

，调用

create_breakpoint

，这也是

break_命令

调用的，因此它们似乎都使用相同的底层机制

主要区别在于

dprintf

传递

dprintf\u断点操作

结构，该结构具有不同的回调，并在

initialize\u断点操作

处初始化

dprintf

存储的命令字符串列表与

命令的列表非常相似，具体取决于设置。它们是：


设置为
update\u dprintf\u command\u list
在
type==bp\u dprintf
检查内部
init\u断点\u sal
由
create\u断点
调用

到达断点时：


bpstat\u stop\u status
被调用并调用
b->ops->after\u condition\u true（bs）

dprintf的
after_condition_true
为
dprintf_condition_true

bpstat\u do\u actions\u 1
运行命令
有两个主要区别

首先，
dprintf
有一些额外的输出模式，可用于以其他方式工作。有关更多信息，请参阅帮助设置dprintf频道或手册。我认为这些模式是
dprintf
作为单独实体添加的原因；但与此同时，它们相当专业，不太可能引起普遍兴趣

不过，更有用的是，
dprintf
不会干扰
next
。如果您编写一个断点并使用
命令
，然后在该断点上使用
下一个
，gdb将忘记
下一个
，就像您键入了
继续
一样。这是gdb脚本语言中长期存在的一个奇怪现象
dprintf
不会出现此问题。（如果您需要从普通断点获得类似的功能，可以从Python获得。）