Re: [PATCH v2 bpf-next][RFC] libbpf: introduce legacy kprobe events support

[Rafael David Tinoco <rafaeldtinoco@ubuntu.com>]

>> Yes, with a small reservation I just found out: function names might
>> change because of GCC optimisations.. In my case I found out that:
>> 
>> # cat /proc/kallsyms | grep udp_send_skb
>> ffffffff8f9e0090 t udp_send_skb.isra.48
>> 
>> udp_send_skb probe was not always working because the function name
>> was changed. Then I saw BCC had this issue back in 2018 and is
>> fixing it now:
>> 
>> https://github.com/iovisor/bcc/issues/1754
>> https://github.com/iovisor/bcc/pull/2930
>> 
>> So I thought I could do the same: check if function name is the same
>> in /proc/kallsyms or if it has changed and use the changed name if
>> needed (to add to kprobe_events).
>> 
>> Will include that logic and remove the ‘enables’.
> 
> No, please stop adding arbitrary additions. Function renames, .isra
> optimizations, etc - that's all concerns of higher level, this API
> should not try to be smart. It should try to attach to exactly the
> kprobe specified.

:\ how can this be done in a higher level if it needs to be done
runtime at the time the event is being enabled ? skel will contain
hardcoded kprobe names and won’t be able to get runtime optimised
symbol names, correct ? (unless bpftool gen generates an intermediate
code to check kallsyms and solve those symbols before calling the lib).

I see BCC has some options for regexing symbol names for the probes… 
obviously in BCC’s case is simpler. 

I made it work by checking kallsyms for the exact symbol and,
if not found, for the variants (only for the legacy kprobe event
probe, but it would work for the current one, passing discovered
symbol name for the ioctl attrs. My WIP version (to clarify what I’m
saying):

https://paste.ubuntu.com/p/DpqDsGdVff/