On Tue, Feb 23, 2021 at 11:08 AM Alexei Starovoitov [off-list ref] wrote:

On 2/23/21 10:55 AM, Yonghong Song wrote:

quoted

quoted

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.