[llvm] [BPF] Define empty set of BPF libcalls (PR #169537)

Tue Dec 2 17:34:34 PST 2025

alessandrod wrote:

> > That would require an _external_ call.
> > But when compiling eBPF rustc forces LTO, all the code is merged in one module and the libcalls are not external.
> > but if the libcall is there (not external), we should use the libcall.
> 
> This doesn't quite work out of the box. The current state of the compiler does not expect for legalization to emit calls to defined functions. This is the complete LTO with compiler-rt/libc use case. The backend needs to know a definitive set of ABI functions that may need to be retained for calls which may be introduced by the legalizer.

Right, then the current state - "assume all libcalls are there" - is better than "no libcalls are there". When compiling rust, the libcalls are there. When compiling with clang no libcalls are there, but nobody effectively uses them to write kernel eBPF programs, and you get the hard error. Not ideal but functional.

> If you linked in this function, then it was unused and dropped, it won't be there after codegen introduces the new references to the function. Relatedly, we need to treat the set of available functions as a dynamic program property which is what I've been working towards.

Yes I understand this problem, and in bpf-linker we ensure that the builtins aren't dropped. I also understand that this mechanism isn't ideal and something probably needs to be done at the LLVM level. 

I'm not saying that the current state is perfect or even good, but it's better than the state we'd get to with this PR merged since it would break most rust programs. 

> > No it's not, because you're removing the option of providing a specialized implementation.
> There still need to be ABI defined bounds on what those function names and other ABI properties are

Right. I'm not against creating new triples or anything. I just don't want to break what works today without having a viable alternative. 

https://github.com/llvm/llvm-project/pull/169537