On 6/11/23 7:57 PM, Steven Rostedt wrote:
On Sun, 11 Jun 2023 22:54:07 -0400
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
Also, if there are multiple same static functions with
different addresses, user space might need to check dwarf or
proposed BTF_KIND_KFUNC (which encode kallsyms addresses)
to find whether entry in available_filter_functions_addrs
to be used. But addresses may not match. How this issue could
be resolved?
Easy, you use the address between two other addresses in kallsyms. The
address is still in the function. The addresses in kallsyms is the starting
address, but there's cases that the patch location is not at the start.
Not to mention, you can still use the kallsyms address. If you did the work
to find it, then use it (it may not be as efficient as I mentioned before).
That's basically what is done today (so I am told), and this patch was to
create a file where you don't need to look up kallsyms when you know which
function to use. The functions are sorted by address, so if you know of a
unique function near the duplicate, you just find the duplicate that's near
the unique function name.
Thanks for explanation. IIUC, typically with endbr enabled, the patch
address typically is the entry_addr + 4. So it is indeed easy to
correlate the entry in available_filter_functions_addrs and in
kallsyms.
I am actually interested in how available_filter_functions_addrs
will be used. For example, bpf_program__attach_kprobe_multi_opts()
can already take addresses from kallsyms. How to use
available_filter_functions_addrs to facilitate kprobe_multi?
Do we need to change kernel APIs? It would be great at least we
got a RFC patch to answer these questions.
-- Steve
