假如已知堆栈中r2寄存器的地址有个具体的值，是否能跟踪该值得来源

技能讨论
1

:slight_smile: 比如，目前下断点到某个函数A，函数A中带有一个参数C，那么此时断点停留在A的入口处，调用命令，po $x2，打印寄存器x2的值，也就是参数C的值，比如是一个字符串，或是另外一个函数调用的返回值当作参数，我怎么能lldb调试跟踪到该地址，也就是参数C的来源？

2

bt看调用战啊

3

bt后，我的理解是只能看到执行的方法顺序，我想问bt应该怎么看:smiley:

=====

我bt后，如下：

thread #7: tid = 0x6bf6, 0x0000000198b8f910 ITMLKit`-[XXXXXXX send:], name = ‘ITMLKit’, stop reason = breakpoint 1.1

  • frame #0: 0x0000000198b8f910 ITMLKit-[XXXXXXX send:] frame #1: 0x000000018b63b150 CoreFoundationinvoking_ + 144
    frame #2: 0x000000018b52deac CoreFoundation-[NSInvocation invoke] + 284 frame #3: 0x000000018fc7f2c8 JavaScriptCoreJSC::ObjCCallbackFunctionImpl::call(JSContext*, OpaqueJSValue*, unsigned long, OpaqueJSValue const* const*, OpaqueJSValue const**) + 404
    frame #4: 0x000000018fc7e7f4 JavaScriptCoreJSC::objCCallbackFunctionCallAsFunction(OpaqueJSContext const*, OpaqueJSValue*, OpaqueJSValue*, unsigned long, OpaqueJSValue const* const*, OpaqueJSValue const**) + 256 frame #5: 0x000000018fc7ed04 JavaScriptCorelong long JSC::APICallbackFunction::callJSC::ObjCCallbackFunction(JSC::ExecState*) + 416
    frame #6: 0x000000018f57980c JavaScriptCoreJSC::LLInt::setUpCall(JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 480 frame #7: 0x000000018fc6061c JavaScriptCorellint_entry + 24876
    frame #8: 0x000000018fc605c8 JavaScriptCorellint_entry + 24792 frame #9: 0x000000018fc605c8 JavaScriptCorellint_entry + 24792
    frame #10: 0x000000018fc5a328 JavaScriptCorevmEntryToJavaScript + 264 frame #11: 0x000000018fb2ca68 JavaScriptCoreJSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) + 168
    frame #12: 0x000000018f57d8c4 JavaScriptCoreJSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 352 frame #13: 0x000000018fb5d170 JavaScriptCoreJSC::boundThisNoArgsFunctionCall(JSC::ExecState*) + 448
    frame #14: 0x000000018fc5a470 JavaScriptCorevmEntryToNative + 272 frame #15: 0x000000018f57d908 JavaScriptCoreJSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 420
    frame #16: 0x000000018f7f09f8 JavaScriptCoreJSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 160 frame #17: 0x000000018f57d678 JavaScriptCoreJSObjectCallAsFunction + 536
    frame #18: 0x000000018fc11558 JavaScriptCore-[JSValue callWithArguments:] + 304 frame #19: 0x00000001000b4a50 AppStore_mh_execute_header + 51792
    frame #20: 0x0000000198b31a60 ITMLKit-[IKAppContext _doEvaluate:] + 336 frame #21: 0x0000000198b31654 ITMLKit-[IKAppContext _evaluate:] + 156
    frame #22: 0x0000000198b2df88 ITMLKit__41-[IKAppContext evaluate:completionBlock:]_block_invoke + 44 frame #23: 0x0000000198b313e4 ITMLKit-[IKAppContext _sourcePerform] + 352
    frame #24: 0x0000000198b3123c ITMLKitIKRunLoopSourcePerformCallBack + 40 frame #25: 0x000000018b5e2b5c CoreFoundationCFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 24
    frame #26: 0x000000018b5e24a4 CoreFoundation__CFRunLoopDoSources0 + 524 frame #27: 0x000000018b5e00a4 CoreFoundation__CFRunLoopRun + 804
    frame #28: 0x000000018b50e2b8 CoreFoundationCFRunLoopRunSpecific + 444 frame #29: 0x0000000198b3108c ITMLKit-[IKAppContext _jsThreadMain] + 368
    frame #30: 0x000000018c148e68 Foundation__NSThread__start__ + 1024 frame #31: 0x000000018a6c9850 libsystem_pthread.dylib_pthread_body + 240
    frame #32: 0x000000018a6c9760 libsystem_pthread.dylib_pthread_start + 284 frame #33: 0x000000018a6c6d94 libsystem_pthread.dylibthread_start + 4

=========
register read 后如下：

General Purpose Registers:
x0 = 0x00000001741b6340
x1 = 0x0000000197e1f522
x2 = 0x000000017483f220
x3 = 0x0000000000000000
x4 = 0x0000000000000000
x5 = 0x0000000000000000
x6 = 0x0000000000000000
x7 = 0x0000000000000000
x8 = 0x0000000000000000
x9 = 0x0000000197e1f522
x10 = 0x000000012e954e00
x11 = 0x000000430000007f
x12 = 0x000000012e955020
x13 = 0x000001a1b002a7bd
x14 = 0x0000000002f405c0
x15 = 0x0000000002f40501
x16 = 0x00000001b002a7b8 (void *)0x000001a1b002a7e1
x17 = 0x0000000198b8f910 ITMLKit-[XXXXXXX send:] x18 = 0x0000000000000000 x19 = 0x0000000174666000 x20 = 0x000000017022b920 x21 = 0x000000018a07ef60 libobjc.A.dylibobjc_msgSend
x22 = 0x000000012dda4250
x23 = 0x000000012dda4390
x24 = 0x0000000000000018
x25 = 0x0000000000000008
x26 = 0x0000000000000002
x27 = 0x0000000000000001
x28 = 0xffff000000000002
fp = 0x000000016e7ace80
lr = 0x000000018b63b150 CoreFoundation__invoking___ + 144 sp = 0x000000016e7ace70 pc = 0x0000000198b8f910 ITMLKit-[XXXXXXX send:]
cpsr = 0x60000000

4

你的参数就是stack的上一层传给你的啊。lldb只能做到这个精确度据我所知。要特别标准你可能就只能自己构造AST树了

5

我想是否能在x2的地址那里下个断点，然后重新运行程序。于是试了下，程序直接报错:stop reason = EXC_BAD_ACCESS，估计是这个地址0x000000017483f220有问题，不能断点下来。那么在lldb中又如何打印出上一层的堆栈信息呢 :smiley:

6

是不是把调用函数A起始地址，前面例如1000字节反汇编出来，看哪里赋值的x2寄存器的值，依次往上找。我想这样的话，假如前面有直接跳转过来地址那种，这样分析就有可能不对。

7

是的所以你需要构建完整AST。贼坑不建议考虑

8

岂不是找到参数来源很麻烦，我才接触这种是不是就搞不出来了。:joy:

9

只能自己看汇编手动分析调用链啊

10

可以用malloc stack找到内存的创建地点。参考http://www.jianshu.com/p/759015369b6f

11

也是卡在这，你那边有其他方法追踪吗