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

[Matt Arsenault via llvm-commits]

arsenm 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

> 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. 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. 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.

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