我正在尝试使用 gdb 调试 iOS 应用程序，当我遇到断点时出现此错误，并且无法继续。
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to process 190 thread 0x6fa7]
0x000ae150 in dyld_stub_pthread_key_create ()
有谁知道如何在不关闭和重新打开 gdb 的情况下继续调试？
SIGTRAP 后无法继续调试
逆向工程
艾达
拆卸
部件
数据库
ios
2021-06-22 05:17:14
3个回答
如果您的断点地址位于操作码的“中间”，则可能会发生这种情况，例如，如果您的 asm 代码如下所示：
0x000C: BLX R3
0x000E: LDR R0, [R6]
并且您在地址 0x00D 上放置断点，在这种情况下，进程将在 0x000D 以外的其他地址上获得 SIGTRAP，但 gdb 只知道来自用户输入的 0x00D 地址，因此它只会抛出 SIGTRAP 并卡住。
此外，即使您将正确的地址写入 gdb，gdb 的 arm 回退模式也会导致此类问题。
set arm fallback-mode (arm|thumb|auto)
GDB uses the symbol table, when available, to determine whether instructions are ARM or Thumb. This command controls GDB’s default behavior when the symbol table is not available. The default is ‘auto’, which causes GDB to use the current execution mode (from the T bit in the CPSR register).
有时 gdb 无法自动获取函数的 arm 模式，并陷入错误的模式。您可以通过反汇编 gdb 中的一段代码来检查这一点，并检查您是否看到正常的汇编或一些错误的汇编。如果它是坏的，那么你的手臂组装模式是错误的，你可能会得到错误的 SIGTRAP。
另一个建议是在iOS中不要使用gdb，使用lldb。gdb 已贬值，iOS 唯一可用的 gdb 版本是个人编写的端口，这些端口缺乏功能（例如其中一些根本没有回退功能），并且不可靠。
如果程序出于某种奇怪的原因合法地触发了 SIGTRAP 本身，并且依赖于这种情况的发生，那么您可以通过执行以下命令告诉 gdb 返回到程序并执行程序自己的 SIGTRAP 处理：
signal SIGTRAP
这就像ccontinue 一样，除了它在 SIGTRAP 处理程序处继续，而不是在引发异常/陷阱的地方继续。
如果Received a SIGTRAP: Trace/breakpoint trap即使程序中没有断点也遇到此错误，请检查硬件调试器（例如 J-Link）的功能。
就我而言，J-Link 已开启，但端口没有提供足够的电力。将端口更改为高功率端口可以解决此问题。