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

[Alessandro Decina via llvm-commits]

alessandrod wrote:

> > I fail to see what this PR is fixing: what gets better? What use case gets unlocked?
> 
> This fixes erroring on memory intrinsics and other cases that by default want to legalize libcalls

In what workflow exactly? Rust provides the libcalls, clang and people who use BPF in C never use libcalls.

> 
> > This prompted me to investigate more what aya's bpf-linker is doing, and I bumped in these lines on the error handling function https://github.com/aya-rs/bpf-linker/blob/3af0b17c22a8a35f6f9d4fac4e3a6af5ef4444c8/src/linker.rs#L799-L806, which, when, commented out, cause the compilation for the Rust example provided in the previous message to fail with the error:
> 
> This is absurd. Clients of the backend should not be scraping the error log and continuing with the failed compile.
> 
> > As things are now, this is just an unnecessary breaking change for the whole rust eBPF ecosystem.
> 
> Based on above, I don't think so. If the linker you're relying on is doing some weird hack where it suppresses the error, and then patches in some symbols on failed calls, and then it happens to work.

Yeah the other PR to remove the error also achieves this right?

> This will avoid failing on those calls in the first place. If you actually want to rely on external calls, the triple / ABI work needs to happen.

And you don't think it makes sense for that work to happen _first_? You're taking away some functionality without providing an alternative. 

> As it stands, this change puts the de-facto behavior of the backend on more stable footing. The current linker hack doesn't break, it will just become a no-op since the references to memcpy won't be attempted in the first place.

Again, this completely disregards how BPF actually works. This will increase the number of instructions in the bytecode, reducing the budget the verifier checks against. The verifier verifies global vs static functions using different algorithms, and this change makes it impossible to define memory and other libcalls as global. 

Feels like you're doing this change completely disregarding how people actually _use_ the target. I really don't understand why the bright new future can't happen _first_. 

The way I see it you're taking away some functionality. After this lands, it's unclear that there is incentive for the OP to fix my use case (since he doesn't use kernel eBPF) and go and update the rust toolchain, and therefore are forcing me to have to do a whole bunch of new work. 

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