“svc #128”意外闯入调试器 - 如何调试？答案

【问题标题】："svc #128" breaking in to debugger unexpectedly - how to debug?“svc #128”意外闯入调试器 - 如何调试？
【发布时间】：2015-03-02 06:52:07
【问题描述】：

有一系列 StackOverflow 问题提到在 svc #128 指令后意外闯入调试器。在我自己处理这个问题时，我想问一些一般性的问题，关于何时以及为什么会发生这种情况。

svc #128 在 iOS 中的具体用途是什么？
是什么导致它闯入调试器？
有没有办法在开发过程中抑制闯入调试器？
调试此问题的根本原因的可能方法？
人们过去使用过的成功修复程序？

【问题讨论】：

SVC ("Supervisor Call") 只是 ARM 系统调用指令。 A quick poke around 透露，与大多数现代事物一样，iOS 使用基于寄存器的系统调用约定，因此 #128 在很大程度上无关紧要，但其他程序状态很重要。我不了解 iOS，但一般来说，意外闯入调试器意味着如果您没有附加调试器，您就会崩溃 - this seems relevant。考虑到这一点，“我如何（通常）调试不可靠的代码？”这个问题显然太宽泛了。
感谢您的评论。事实证明，在这种情况下，我的代码工作正常。问题是 LLDB 默认情况下会在某些线程到线程信号上中断，例如SIGUSR2 ...一旦我将调试器设置为忽略它并自动继续执行，它就可以正常工作。作为汇编程序，之前的调用是movz x16, #328，它对应于您有用链接中的 pthread_kill。

标签： xcode debugging assembly arm

【解决方案1】：

svc #128 或 svc 0x80 调用是 ARM 指令集 (ARM Documentation) 中的 Supervisor Call。您需要查看寄存器值以指示正在调用的内容。

示例汇编器：

libsystem_kernel.dylib`__pthread_kill:
0x195557268:  movz   x16, #328                 // NOTE THIS VALUE
0x19555726c:  svc    #128
0x195557270:  b.cc   0x195557288               ; __pthread_kill + 32
...

在此Kernel System Calls 表中查找movz 值（在本例中为#328）。对于#328，这对应于pthread_kill，它与上面列出的方法的名称相匹配。当中断被调用时，它将立即落在svc之后的指令上，在这个例子中是b.cc指令。

请注意，对于某些线程到线程的信号，LLDB 也会中断，例如SIGUSR2，即使它是故意和正确的。您可以将 Xcode 配置为忽略这一点并继续执行而不会出现问题：

Permanently configuring LLDB (in Xcode 4.3.2) not to stop on signals

感谢 Notlikethat 的投入

【讨论】：