比如,目前下断点到某个函数A,函数A中带有一个参数C,那么此时断点停留在A的入口处,调用命令,po $x2,打印寄存器x2的值,也就是参数C的值,比如是一个字符串,或是另外一个函数调用的返回值当作参数,我怎么能lldb调试跟踪到该地址,也就是参数C的来源?
bt看调用战啊
bt后,我的理解是只能看到执行的方法顺序,我想问bt应该怎么看
=====
我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 CoreFoundation
invoking_ + 144
frame #2: 0x000000018b52deac CoreFoundation-[NSInvocation invoke] + 284 frame #3: 0x000000018fc7f2c8 JavaScriptCore
JSC::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 JavaScriptCore
long 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 JavaScriptCore
llint_entry + 24876
frame #8: 0x000000018fc605c8 JavaScriptCorellint_entry + 24792 frame #9: 0x000000018fc605c8 JavaScriptCore
llint_entry + 24792
frame #10: 0x000000018fc5a328 JavaScriptCorevmEntryToJavaScript + 264 frame #11: 0x000000018fb2ca68 JavaScriptCore
JSC::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 JavaScriptCore
JSC::boundThisNoArgsFunctionCall(JSC::ExecState*) + 448
frame #14: 0x000000018fc5a470 JavaScriptCorevmEntryToNative + 272 frame #15: 0x000000018f57d908 JavaScriptCore
JSC::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 JavaScriptCore
JSObjectCallAsFunction + 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 CoreFoundation
CFRUNLOOP_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.dylib
thread_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.dylib
objc_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
你的参数就是stack的上一层传给你的啊。lldb只能做到这个精确度据我所知。要特别标准你可能就只能自己构造AST树了
我想是否能在x2的地址那里下个断点,然后重新运行程序。于是试了下,程序直接报错:stop reason = EXC_BAD_ACCESS,估计是这个地址0x000000017483f220有问题,不能断点下来。那么在lldb中又如何打印出上一层的堆栈信息呢
是不是把调用函数A起始地址,前面例如1000字节反汇编出来,看哪里赋值的x2寄存器的值,依次往上找。我想这样的话,假如前面有直接跳转过来地址那种,这样分析就有可能不对。
是的所以你需要构建完整AST。贼坑不建议考虑
岂不是找到参数来源很麻烦,我才接触这种是不是就搞不出来了。
只能自己看汇编手动分析调用链啊
可以用malloc stack找到内存的创建地点。参考http://www.jianshu.com/p/759015369b6f
也是卡在这,你那边有其他方法追踪吗