【发布时间】：2012-04-11 11:44:01
【问题描述】：
我正在尝试在这里做一些花哨的事情，但文档表明它应该是可能的。也许 LLDB 仍然太新，但我遇到了很多调试器崩溃/死锁，即使没有发生这种情况，它似乎也没有像我预期的那样工作。
我正在尝试围绕所有选择器调用组合一个调试包装器，以在特定代码块中提取消息调用图。 （如果您真的想知道，我可以解释为什么，但这与调试器问题并不真正相关。）
我从要开始跟踪事物的行上的 Xcode 断点开始（对于奖励积分，这发生在辅助线程上，但在你问之前，不，任何其他线程上都没有对任何其他线程进行任何访问此对象或其属性子图中的任何内容）：
[myObject startProcessing];
断点触发，我运行“bt”，只是为了提取：
* thread #5: tid = 0x2203, 0x000277d2 .........
然后我做了一些有点邪恶的事情：我在 objc_msgSend 中设置了一个断点，就在它调用真实对象选择器的指令处。 objc_msgSend 看起来像：
libobjc.A.dylib`objc_msgSend:
...(instructions)...
0x37babfa4: bx r12
...(more instructions)...
（实际上有两个 bx 调用，但让我们保持简单。）我运行：
breakpoint set -a 0x37babfa4 -t 0x2203
（包含 TID 是因为我在跟踪这一线程时遇到了很多麻烦，而且我不需要无关的东西干扰。）
这就是脚本的用武之地。上面描述的设置完全按照我的意愿工作。如果我继续执行直到断点触发，我可以运行：
frame select 0
thread step-inst -m this-thread 5
frame info
continue
效果将是调试器：
- 移动到 objc_msgSend 帧
- 逐条指令，将其推进到它所指向的对象选择器框架中
- 显示相关详细信息（对象类型、调用的选择器）
- 恢复执行
此时我可以一遍又一遍地粘贴这四个命令并复制输出，直到我讨厌自己为止。
另一方面，如果我运行：
breakpoint command add -s command
并粘贴那些 完全相同的命令，一切都会中断。它不会前进到对象选择器框架。它不显示帧细节，或者至少不显示正确的细节——取决于各种调整（见下文），它可能会或可能不会将“objc_msgSend”显示为当前函数。它不会恢复执行。
在这种情况下，如果我能让该示例正常运行，我会非常高兴。但是为了获得更多奖励积分，我也尝试过使用 python，我更喜欢它，因为它可以实现更复杂的日志记录：
breakpoint command add -s python
> thread = frame.GetThread()
> thread.StepInstruction(1)
> newFrame = thread.GetFrameAtIndex(0)
> print " " * thread.GetNumFrames() + newFrame.GetFunctionName()
> process = thread.GetProcess()
> process.Continue()
> DONE
又不行了。同样取决于微小的细节，这可能会或可能不会打印 something（通常是 objc_msgSend），但它永远不会打印正确的东西。它永远不会将指令向前推进。之后它永远不会恢复执行。
再一次，如果我手动操作，python 版本可以正常工作：如果我等到断点触发，然后运行“脚本”并输入完全相同的行，它会按预期工作。有些部分甚至可以单独工作，例如如果我删除除获取进程并调用 process.Continue() 并自动触发这些部分之外的所有内容，则“有效”（意味着我看到 lldb 提示在暂停和恢复执行时快速闪烁。通常我对此感到遗憾，因为它变成了无响应并在不久后崩溃。）
那么：有什么想法吗？是技术还没有准备好，还是我只是错过了一些可以解决所有问题的聪明拼图？还是我应该完全放弃并接受对象内部的某些部分我永远无法理解的事实？...
【问题讨论】：
-
在使用 LLDB 进行调试时，还有其他关于 SO 报告问题的问题。我知道的一个问题（但找不到参考文献）报告了在切换回 GDB 时问题消失了。我猜它还不是gasp成熟的产品。
-
@PeterM：是的，我从来没有遇到过（很多）gdb 有问题的麻烦，但是对于像这样更花哨的东西，它的功能受到了很多限制。也许我确实需要切换回来并在几个版本中重试......
标签： ios xcode cocoa-touch debugging lldb