我正在尝试在这里做一些花哨的事情,但文档建议它应该是可能的。也许 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
又不行了。同样取决于微小的细节,这可能会或可能不会打印一些东西(通常是 objc_msgSend),但它永远不会打印正确的东西。它永远不会将指令向前推进。之后它永远不会恢复执行。
再说一次,如果我手动操作,python 版本可以正常工作:如果我等到断点触发,然后运行“脚本”并输入完全相同的行,它会按预期工作。有些部分甚至可以单独工作,例如,如果我删除除获取进程并调用 process.Continue() 的部分之外的所有内容并自动触发这些部分,则“有效”(这意味着我看到 lldb 提示在暂停和恢复时快速闪烁执行。通常我会后悔,因为它很快就会变得无响应并崩溃。)
所以:有什么想法吗?是技术还没有准备好,还是我只是错过了一些可以解决所有问题的聪明拼图?还是我应该完全放弃并接受这样一个事实,即对象内部的某些部分我永远无法理解?...