On Fri, 13 Sep 2024 17:59:35 +0900 Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx> wrote: > > > > Taking failing output from the test: > > > > > > > kprobe_multi_testmod_check:FAIL:kretprobe_test3_result unexpected kretprobe_test3_result: actual 0 != expected 1 > > > > kretprobe_test3_result is a sort of identifier for a test condition, > > you can find a corresponding line in user space .c file grepping for > > that: > > > > ASSERT_EQ(skel->bss->kretprobe_testmod_test3_result, 1, > > "kretprobe_test3_result"); > > > > Most probably the problem is in: > > > > __u64 addr = bpf_get_func_ip(ctx); > > Yeah, and as I replyed to another thread, the problem is > that the ftrace entry_ip is not symbol ip. > > We have ftrace_call_adjust() arch function for reverse > direction (symbol ip to ftrace entry ip) but what we need > here is the reverse translate function (ftrace entry to symbol) > > The easiest way is to use kallsyms to find it, but this is > a bit costful (but it just increase bsearch in several levels). > Other possible options are > > - Change bpf_kprobe_multi_addrs_cmp() to accept a range > of address. [sym_addr, sym_addr + offset) returns true, > bpf_kprobe_multi_cookie() can find the entry address. > The offset depends on arch, but 16 is enough. Oops. no, this bpf_kprobe_multi_cookie() is used only for storing test data. Not a general problem solving. (I saw kprobe_multi_check()) So solving problem is much costly, we need to put more arch- dependent in bpf_trace, and make sure it does reverse translation of ftrace_call_adjust(). (this means if you expand arch support, you need to add such implementation) Thank you, -- Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
