Question

我在lldb中设置了很多断点，用于我在MacOS上安装的基于C语言的应用程序。断点大多设置在应用程序的相同功能中。但是，第二天我回到应用程序继续处理它，并且我开始在同一个函数中再次设置断点，出现了一个问题，即在应用程序函数内部没有发生中断，而是在其中一个应用程序的底层库，每当我尝试打破函数时它会一遍又一遍地执行此操作（即它在底层库中停止）并且我无法通过步进（每次我步进）达到所需的功能，它只是在底层库中前进。

更新

我在设置断点的函数是从信号处理程序中调用的。例如，当我发送一个SIGINT信号时，信号处理程序调用一些函数来清理应用程序，我在其中一个清理函数上设置断点。有时，LLDB在我设置断点的函数中停止（使用stop reason = breakpoint 1.1），有时它会在stop reason = signal SIGSTOP的基础/包含事件处理库中停止，如果是后者，则按“c” “（希望继续进入应用程序中的断点并从事件处理库中继续），有时它只会让我继续进入所需的断点，其他只是说”进程41524恢复“并且我永远无法达到所需的断点

Answer 1

啊，那么我认为问题不在于断点，而在于你的信号处理程序是否真的被调用了。

大多数调试器都有一些方法来控制收到信号时会发生什么。在lldb中，这是通过process handle命令完成的。例如：

(lldb) process handle SIGSTOP
NAME         PASS   STOP   NOTIFY
===========  =====  =====  ======
SIGSTOP      false  true   true

这意味着lldb将在您的进程被给予SIGSTOP时停止，并将通知您有关SIGSTOP的信息，但不会将SIGSTOP传递给您正在调试的程序（因此不会为SIGSTOP调用您的处理程序。）没有参数的process handle将为您提供所有信号的行为列表。

我们默认不传递SIGSTOP，因为调试器将其用于自己的目的，因此您可能会调用不是来自“真正的”SIGSTOP的处理程序。出于同样的原因，SIGINT也是如此：

(lldb) process handle SIGINT
NAME         PASS   STOP   NOTIFY
===========  =====  =====  ======
SIGINT       false  true   true

您可以轻松更改此行为，例如SIGINT：

(lldb) process handle SIGINT -p true
NAME         PASS   STOP   NOTIFY
===========  =====  =====  ======
SIGINT       true   true   true

然后调试器会将SIGINT传递给进程，它将在你的处理程序中停止。

Answer 2

如故障排除指南中所述，向.lldbinit文件添加target.inline-breakpoint-strategy设置似乎可以解决问题

 "settings set target.inline-breakpoint-strategy always" >> ~/.lldbinit

更新：问题未修复，请参阅OP，因此这不是一个好的解决方案（AFAIK）

如何告诉LLDB将信号传递到节目

2 个答案: