On Fri, 13 Sep 2024 21:45:15 +0900 Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx> wrote: > 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) OK, can you try this one?
