再看perf是如何通过dwarf处理栈帧的

从结构体stack_dump入手，

util/unwind-libunwind-local.c 中有函数access_mem

#0  access_mem (as=0x1f65bd0, addr=140221249831136, valp=0x7fffffffa930, __write=0, arg=0x7fffffffb900) at util/unwind-libunwind-local.c:452
#1  0x00007ffff6c171ec in _Ux86_64_dwarf_search_unwind_table () from /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8
#2  0x000000000052cd16 in find_proc_info (as=0x1f65bd0, ip=140221248995871, pi=0x7fffffffb620, need_unwind_info=1, arg=0x7fffffffb900)
    at util/unwind-libunwind-local.c:364
#3  0x00007ffff6c13e75 in ?? () from /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8
#4  0x00007ffff6c159e7 in ?? () from /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8
#5  0x00007ffff6c16cd9 in ?? () from /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8
#6  0x00007ffff6c0f671 in _Ux86_64_step () from /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8
#7  0x000000000052c48c in get_entries (ui=ui@entry=0x7fffffffb900, cb=0x4c0ff0 <unwind_entry>, arg=0x7ffff7fcf758, max_stack=127)
    at util/unwind-libunwind-local.c:648
#8  0x000000000052c6c2 in _unwind__get_entries (cb=<optimized out>, arg=<optimized out>, thread=<optimized out>, data=<optimized out>,
    max_stack=<optimized out>) at util/unwind-libunwind-local.c:686
#9  0x00000000004c652c in thread__resolve_callchain_unwind (max_stack=127, sample=0x7fffffffbb60, evsel=0x1ee46f0, cursor=0x7ffff7fcf758,
    thread=0x1f42060) at util/machine.c:1941
#10 thread__resolve_callchain (thread=0x1f42060, cursor=0x7ffff7fcf758, evsel=0x1ee46f0, sample=0x7fffffffbb60, parent=0x7fffffffba68,
    root_al=0x7fffffffba00, max_stack=127) at util/machine.c:1968
#11 0x00000000004bf181 in sample__resolve_callchain (sample=<optimized out>, cursor=<optimized out>, parent=parent@entry=0x7fffffffba68,
    evsel=<optimized out>, al=al@entry=0x7fffffffba00, max_stack=max_stack@entry=127) at util/callchain.c:803
#12 0x00000000004ed711 in hist_entry_iter__add (iter=0x7fffffffba40, al=0x7fffffffba00, max_stack_depth=127, arg=0x7fffffffc0e0)
    at util/hist.c:1023
#13 0x000000000043208e in process_sample_event (tool=0x7fffffffc0e0, event=<optimized out>, sample=0x7fffffffbb60, evsel=<optimized out>,
    machine=<optimized out>) at builtin-report.c:192
#14 0x00000000004cb1fa in perf_evlist__deliver_sample (machine=<optimized out>, evsel=0x1ee46f0, sample=0x7fffffffbb60, event=0x7ffff7ff5578,
    tool=0x7fffffffc0e0, evlist=0x1ee3cb0) at util/session.c:1196
#15 machines__deliver_event (machines=machines@entry=0x1ee39f8, evlist=0x1ee3cb0, event=event@entry=0x7ffff7ff5578,
    sample=sample@entry=0x7fffffffbb60, tool=tool@entry=0x7fffffffc0e0, file_offset=file_offset@entry=17784) at util/session.c:1233

是如何处理栈帧的

.... SP    0x7ffd099f2b58
.... IP    0x7f87cdbc821f

然后发现access_mem调用了好多次，可能是因为用户栈大小的问题，是怎么

编译了binary，但是并没有正确解析出函数调用栈，这是因为在我系统的lib64.so中并没有相关的debuginfo，导致在解析getpid函数的时候并没有准确得到调用栈的信息，如果我在func函数的地方打点，那么就不会遇到这个问题了：

试一下

即便在uprobe处打点，为啥只检测出来一层调用栈，看样子是解析出