On 5/22/19 7:02 AM, Peter Zijlstra wrote: > >> If the unwinder could trace back through the bpf func call then there >> will be no such problem. > > Why couldn't it trace back through the bpf stuff? And how can we fix > that? Most of the time there is no 'tracing through bpf stuff'. bpf infra is preserving 'pt_regs*' that was collected before any bpf things start executing. The reason is that bpf can be executed via interpreter and directly when JITed. In both cases collected stack traces should be the same or it's confusing the users and they cannot compensate for such difference. The only exception is raw_tracepoint, since it's the most minimalistic way of calling bpf and kernel side doesn't do anything before calling into bpf. Only in such case bpf side has to call perf_fetch_caller_regs(). See bpf_get_stackid_raw_tp(). But this test case is actually working! It's covered by prog_tests/stacktrace_map_raw_tp.c and it passes. The one that is broken is prog_tests/stacktrace_map.c There we attach bpf to standard tracepoint where kernel suppose to collect pt_regs before calling into bpf. And that's what bpf_get_stackid_tp() is doing. It passes pt_regs (that was collected before any bpf) into bpf_get_stackid() which calls get_perf_callchain(). Same thing with kprobes, uprobes.
