On Tue, Feb 23, 2021 at 11:08 AM Alexei Starovoitov <ast@xxxxxx> wrote: > > On 2/23/21 10:55 AM, Yonghong Song wrote: > >> BTW, doesn't Clang emit instruction with BPF_PSEUDO_FUNC set properly > >> already? If not, why not? > > > > This is really a contract between libbpf and kernel, similar to > > BPF_PSEUDO_MAP_FD/BPF_PSEUDO_MAP_VALUE/BPF_PSEUDO_BTF_ID. > > Adding encoding in clang is not needed as this is simply a load > > of function address as far as clang concerned. > > Andrii, I had the same thought when I first looked at it. > The llvm can be taught to do this, but it would be a change in behavior. > Older llvms will generate relo while new one will not. > To ease adoption libbpf would probably need to support both. > Hence no real need to tweak llvm. > If we go with llvm only approach my ongoing work on naked functions > would require to tweak llvm and libbpf again. > While the llvm does the same relo for naked funcs already. > So I will reuse this libbpf support as-is. > Only for &&label and jmptables the extra llvm work will be needed. Yeah, that's fine. I wasn't complaining :) It would be safer if LLVM emitted the intent, but it's fine, libbpf seems to be doing fine inferring it. I was also under the impression we do get BPF_PSEUDO_xxx for other types of relos (for whatever reason), which is not really the case.
