On Wed, Apr 14, 2021 at 10:53 PM Rafael David Tinoco <rafaeldtinoco@xxxxxxxxxx> wrote: > > > >> 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). user-space code can specify whichever kernel function name it needs with direct call to bpf_program__attach_kprobe(). bpf_program__attach_kprobe() should attempt to attach *exactly* to the function specified, even if it doesn't exist. That's not the place to make any substitutions, otherwise that API will become an unreliable mess. > > I see BCC has some options for regexing symbol names for the probes… > obviously in BCC’s case is simpler. That regexing can be built on top of bpf_program__attach_kprobe(), if necessary. If user says 'attach to X', API should attach to "X", not "X.something". > > 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/