iOS:LLDB多行断点命令无法按预期工作

iOS:LLDB多行断点命令无法按预期工作,第1张

概述我试图在这里做一些有点花哨的事情,但是文档建议它应该是可能的.也许LLDB仍然是新的,但我得到了很多调试器崩溃/死锁,即使没有发生它似乎没有像我预期的那样工作. 我正在尝试围绕所有选择器调用组装一个调试包装器,以在一定代码块中提取消息调用图. (我可以解释为什么如果你真的想知道,但它与调试器问题并不真正相关.) 我开始在我要开始跟踪事物的行上有一个Xcode断点(对于奖励积分,这发生在辅助线程上, 我试图在这里做一些有点花哨的事情,但是文档建议它应该是可能的.也许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 0thread step-inst -m this-thread 5frame infocontinue

并且效果将是调试器:

>移动到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提示在暂停并恢复执行时快速闪烁.通常我后悔因为它变成了不久之后没有反应和崩溃.)

那么:有什么想法吗?技术尚未准备就绪,或者我只是错过了一些可以解决所有问题的巧妙拼图?或者我应该完全放弃并且只是存在一些我永远无法理解的对象内部部件这一事实?…

解决方法 断点命令无法恢复执行,然后再次获得控制权,至少在今天.关于如果断点1正在运行该进程然后断点2被击中会发生什么,有很多未解决的问题.除了代码库是否能够真正正确处理嵌套断点(它被设计为……)的整个问题,如果断点2决定执行应该停止是什么意思?断点1的状态被抛弃了吗?

在踩到劣质过程的同时担心断点遇到另一个断点似乎有点深奥,但除非所有细节都已经解决,否则用户很容易在脚下射击.因此,对于今天,断点命令可以在断点被触发时停止或继续运行 – 但是没有任何能力运行一点并进行更多处理.我知道这对于某些任务来说是一个非常有用的功能,但是有很多问题需要在完成之前加以考虑.

在某些情况下,有可能以相反的方式处理它…如果你想在函数lexer()调用函数解析器()时停止它,很容易在lexer()上放置一个断点使用一些python命令将一个堆栈帧放到堆栈中并查看调用函数是什么.如果它不是lexer(),继续.不过,我不认为这会适用于你想要做的事情.

总结

以上是内存溢出为你收集整理的iOS:LLDB多行断点命令无法按预期工作全部内容,希望文章能够帮你解决iOS:LLDB多行断点命令无法按预期工作所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/web/1007356.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-22
下一篇 2022-05-22

发表评论

登录后才能评论

评论列表(0条)

保存