Hexagon GDB Debugger介绍(13)

2.9.1.7 断点回调

您可以将回调过程分配给任何断点（或观察点或捕获点）。 当模拟器遇到回调时，它会调用指定的调试器命令或 Tcl 脚本过程（第 4.4 节）。

setproc bnum procname
将指定的调试器命令或脚本过程分配给断点编号 bnum。

如果回调是过程，则忽略任何返回值。

以下示例创建用户定义的 Tcl 脚本过程，然后将其分配给断点：

(hexagon-gdb) proc readFile {} {
% puts “In readFile “
% t_set pVar [output inputfilename]
% }
(hexagon-gdb) b main.c:18
Breakpoint 1 at 0x2118: file ../src/main.c, line 18.
(hexagon-gdb) setproc 1 readFile

如上所示，当调试器处于 Tcl 模式时，提示字符变为 %。

在回调函数中调用时，调试器命令打印（第 2.12 节）和输出（第 4.3.1 节）不显示数据。 要显示回调函数的输出，请使用以下代码序列：

t_set pVar [output x]
puts $pVar

… 其中 pVar 是 Tcl 变量（第 4.4.1 节），t_set 和 puts 是 Tcl 脚本命令。

2.9.1.8 断点命令列表

您可以为任何断点（或观察点或捕获点）分配一系列命令，以便在程序因该断点而停止时执行。 例如，您可能想要打印某些表达式的值，或启用其他断点。

commands [bnum]
… command-list …
end

为断点编号 bnum 指定命令列表。 命令本身出现在以下几行中。 键入仅包含 end 的行以终止命令。

要从断点中删除所有命令，请键入命令并紧随其后使用 end ； 也就是说，不发出任何命令。

如果没有 bnum 参数，命令将引用最后一个断点、观察点或捕获点集（而不是最近遇到的断点）。

在命令列表中禁用按 重复最后一个命令。

您可以使用断点命令再次启动您的程序。 只需使用 continue 命令或 step 或任何其他恢复执行的命令。

在恢复执行的命令之后，命令列表中的任何其他命令都将被忽略。 这是因为任何时候你恢复执行（即使是简单的 next 或 step ），你可能会遇到另一个可能有自己的命令列表的断点，导致关于执行哪个列表的歧义。

注意：
断点命令列表已弃用。 相反，使用断点回调（第 2.9.1.7 节）。

2.9.1.9 断点菜单

一些编程语言（特别是 C++ 和 Objective-C）允许多次定义单个函数名称，以用于不同上下文中的应用程序。 这称为重载。 当函数名被重载时，break 函数不足以告诉调试器你想要断点的位置。 如果您意识到这是一个问题，您可以使用诸如 break 函数（类型）之类的东西来指定您想要哪个特定版本的函数。 否则，调试器会为您提供不同可能断点的编号选项菜单，并等待您通过提示符 > 进行选择。 前两个选项总是 [0] cancel 和 [1] all 。 键入 1 在函数的每个定义处设置一个断点，键入 0 将中止 break 命令而不设置任何新断点。

例如，以下会话摘录显示了在重载符号 String::after 处设置断点的尝试。 我们选择该函数名称的三个特定定义：

(hexagon-gdb) b String::after
[0] cancel
[1] all
[2] file:String.cc; line number:867
[3] file:String.cc; line number:860
[4] file:String.cc; line number:875
[5] file:String.cc; line number:853
[6] file:String.cc; line number:846
[7] file:String.cc; line number:735
> 2 4 6
Breakpoint 1 at 0xb26c: file String.cc, line 867.
Breakpoint 2 at 0xb344: file String.cc, line 875.
Breakpoint 3 at 0xafcc: file String.cc, line 846.
Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
(hexagon-gdb)

2.9.1.10 “无法插入断点”

在某些操作系统下，如果任何其他进程正在运行该程序，则不能在该程序中使用断点。 在这种情况下，尝试使用断点运行或继续程序会导致调试器打印错误消息：

Cannot insert breakpoints.
The same program may be running in another process.

发生这种情况时，您可以通过三种方式继续操作：

• 删除或禁用断点，然后继续。
• 暂停调试器，并将包含您的程序的文件复制到一个新名称。 恢复调试器并使用 exec-file 命令指定它应该在该名称下运行您的程序。 然后再次启动您的程序。
• 使用链接器选项 -N 重新链接您的程序，使文本段不可共享。 操作系统限制可能不适用于不可共享的可执行文件。

如果您请求太多活动的硬件辅助断点和观察点，则会打印类似的消息：

Stopped; cannot insert breakpoints.
You may have requested too many hardware breakpoints and
watchpoints.

当您尝试恢复程序时会打印此消息，因为只有这样调试器才能确切知道它需要插入多少个硬件断点和观察点。

打印此消息时，您需要禁用或删除一些硬件辅助断点和观察点，然后继续。

2.9.1.11 “断点地址调整…”

Hexagon 处理器架构允许将多条指令捆绑到一个指令包中以进行并行执行。 处理器将此类数据包内的断点指令的位置限制为具有最低地址的指令。 调试器通过将断点的地址调整为数据包中的第一条指令来遵守此约束。

优化的处理器代码包含包含来自不同源语句的指令的数据包的情况并不少见； 因此，断点的地址可能会从一个源语句调整到另一个源语句。 由于此调整可能会显着改变调试器与用户期望的断点相关的行为，因此调试器会在首次设置断点以及随后遇到断点时打印警告。

例如，考虑以下指令包：

如果用户使用命令 ‘break *0x4428’在地址 0x4428 上设置断点，调试器会将断点地址调整为数据包中的第一条指令（即 0x4420），然后打印以下警告：

warning: Breakpoint address adjusted from 0x4428 to 0x4420.

对于用户可设置的断点和调试器内部的断点，都会打印此类警告。 如果您看到这些警告之一，您应该验证在调整后的地址处设置的断点是否会产生所需的效果。 如果没有，可以删除有问题的断点，并设置其他具有所需行为的断点。 例如，将断点放在后面的指令中就足够了。 在某些情况下，条件断点也可能有助于防止断点过于频繁地触发。

调试器在调整后的断点处停止时还会打印警告：

warning: Breakpoint 1 address previously adjusted from 0x4428 to 0x4420.

遇到此警告时，采取补救措施可能为时已晚，除非在比预期更早或更频繁地命中断点的情况下。