我正在尝试调试一个程序,该程序通常会导致 GDB 在不在断点处时停止并显示 SIGTRAP。它发生在加载动态库和其他普通东西时。在我的断点最终被击中之前,其中大约有 1,000 个发生,因此我手动“继续”所有这些不相关的 SIGTRAP 是不可行的。但是如果我使用命令 handle SIGTRAP nostop noprint
,那么 GDB 不会停在我的断点处。
似乎必须有一种方法来教育 GDB,使其了解哪些 SIGTRAP 适合停止,哪些不适合停止。显然 GDB 知道它是否在断点处,因为输出非常可靠:在断点处,它提到“断点”并显示断点编号——但在任何其他 SIGTRAP 处,它只说“SIGTRAP”。因此,与其打印有关 SIGTRAP 的消息,我真的希望 GDB 对自己说,“哇,这是一个 SIGTRAP,这里没有断点——看我,我要停下来打印一个完全破坏调试 session 的无用SIGTRAP消息!我继续安静地继续怎么样?如果有人有办法做到这一点,请告诉我。
最佳答案
您可以设置 catchpoints捕捉 SIGTRAP 信号并添加命令来决定是继续还是停止。在此处理程序中,您可以检查 convenience variables如 $_siginfo
因为信号的原因。
特别感兴趣的是 $_siginfo.si_code
,其值取决于传递的信号。 sigaction(2) Linux手册页描述了确切的关系。您可以找到这些 SI_USER
的数值, SI_KERNEL
等通过编译程序或查看标题(在我的系统上它使用标题 /usr/include/bits/siginfo.h
)来编写代码。我遇到的一些值(value)观是:
SI_USER
SI_KERNEL
TRAP_TRACE
有了这些信息,这里是一个捕获 SIGTRAP 并打印原因的示例,然后继续:
catch signal SIGTRAP
commands
p $_siginfo.si_code
c
end
# Set another breakpoint for testing
break sleep
现在考虑这个休眠 5 秒的测试程序,然后在 x86(-64) 上触发调试陷阱:
#include <unistd.h>
int main(void) {
for (;;) {
sleep(5);
asm("int3");
}
return 0;
}
该程序一直停止
gdb
在 int3
行,因为信号被捕获( si_code
恰好是 0x80, SI_KERNEL
),但随后再次重复该指令。所以要跳过这条指令,程序计数器( $pc
)必须递增。这样做之后,我了解到有关SIGTRAP
的信息。和 si_code
:SI_KERNEL
) 触发 SIGTRAP。 TRAP_TRACE
) 的 SIGTRAP(因为 SIGTRAP
的捕获点)。 int3
指令使用代码 128 触发 SIGTRAP。因此您需要一些东西来区分指令。 以下是跳过
int3
的最终 GDB 命令陷阱并仍然保持断点功能:catch signal SIGTRAP
commands
silent # do not print catchpoint hits
# ignore the int3 instruction (this address was looked up at
# the tracepoint using print $pc)
if $pc == 0x400568
set $pc++ # skip int3
c
end
# Ignore TRAP_TRACE that is used for breakpoints
if $_siginfo.si_code == 2
c
end
end
最后一点:SIGTRAP 是调试器内部使用的,有可能上面捕获的太多了。这是在 Arch Linux 上用 GDB 7.10 测试的。
关于gdb - 如何让 GDB 仅在断点处停止在 SIGTRAP?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15667795/