GDB硬件观察点非常慢-为什么？

在大型C应用程序上，我在内存地址上设置了一个硬件观察点，如下所示：

(gdb) watch *0x12F5D58
Hardware watchpoint 3: *0x12F5D58

正如你所看到的，这是一个硬件观察点，而不是软件，这将解释缓慢

现在，调试器下的应用程序运行时间已从不到10秒更改为1小时，并且正在计数。到目前为止，观察点已经触发了三次，第一次是15分钟后，包含地址的内存页被

sbrk

读取。在这15分钟内，由于内存页不可访问，观察点应该是有效的吗？但这仍然不能解释为什么之后会这么慢

平台为x86_64，GDB版本为Ubuntu 9.10软件包：

$ gdb --version
GNU gdb (GDB) 7.0-ubuntu
[...]

和库存GDB 7.1由以下来源构建：

$ gdb-7.1 --version
GNU gdb (GDB) 7.1

提前感谢您提供的有关原因或解决方法的建议

编辑：已删除类型转换

---

编辑：GDB7.1

很可能是因为您每次都在铸造它。试试这个：

(gdb) watch *0x12F5D58

---

另一种选择是设置了太多的硬件观察点，因此gdb被迫使用软件观察点。尝试使用以下方法检查您有多少监视点：

(gdb) info break

---

看看是否可以禁用一些监视点。

我实际上在GDB 7.x.x中遇到了硬件监视点的问题，这是不可接受的，因为监视点是我工作中的必要条件

根据同事的建议，我下载了6.7.1的源代码，并在本地构建了它。监视点现在工作得更好了

---

可能值得一试。

在x86上，您有以下限制：您的所有监视点只能覆盖四个内存地址，每个内存地址可以监视一个内存字-这是因为硬件监视点（快速监视点）使用处理器调试寄存器，而您有四个，因此有四个位置需要观察。

我发现观察大字符缓冲区非常慢，而观察缓冲区中的字符非常快

e、 g

查看buf_地址

——速度极其缓慢

---

watch*buf_address

-非常快。

gdb真的可以取消引用整数文本，而不需要知道取消引用的类型吗？这不是一个有效的C表达式，至少……是的，它可以。我一直这么做。令我惊讶的是（我原以为GDB只接受C表达式）“watch*0x12F5DF8”工作正常，但与上一个版本一样慢。只删除了watchpoint和其他所有内容，性能仍然保持不变。x86_64。对不起，我忘了提一下。在调试器下运行时总是很慢，还是只有在设置了观察点时才慢？很有趣。我将尝试一下。GDB 6.7.1缺少一个功能，可以在内存地址上使用在观察点设置时无法访问的观察点。在正确的时间启用它是可能的，但这将涉及更多内容，我稍后会尝试。我也尝试过刚发布的GDB 7.1，与7.0的问题相同。使用条件断点和断点命令，您可能可以轻松解决这个问题。他已经说过他只有一个观察点，请参阅Nathan回答的第四条评论。

static char buf[1024];
static char* buf_address = &buf;