`--target bpfel-unknown-none` generates LLVM bitcode instead of eBPF

[workingjubilee]

I built this code with cargo build --target bpfel-unknown-none -Zbuild-std:

#![no_std]

#[unsafe(no_mangle)]
#[inline(never)]
pub fn oof(a: u64, b: u64, c: u64, d: u64, e: u64, f: u64, g: u64) -> u64 {
    a + b + c + d + e + f + g
}

#[unsafe(no_mangle)]
pub fn argh(a: u64, b: u64, c: u64, d: u64, e: u64, f: u64, g: u64) -> u64 {
    a + b + c + d + e + f + g
}

I expected to see this happen: An BPF binary was produced of some kind (or compilation failed).

Instead, this happened: It produced LLVM bitcode! this was discovered via (frequent ls omitted):

cargo new bpf-test
cd bpf-test
"$EDITOR" .
cd target
cd bpfel-unknown-none
cd debug
file libbpf_test.rlib
ar x libbpf_test.rlib 
~/.rustup/toolchains/nightly-"$HOST_TUPLE"/lib/rustlib/"$HOST_TUPLE"/bin/llvm-dis bpf_test-*.rcgu.o
"$EDITOR" . bpf_test-*.rcgu.o.ll

This is a bug because we normally require that targets are capable of producing object code. This can be fixed by building the bpf-linker for this target, but I suspect it is mostly like the existing bitcode linker that we already ship for the purposes of the nvptx targets.

Meta

rustc --version --verbose:

rustc 1.85.0-nightly (45d11e51b 2025-01-01)
binary: rustc
commit-hash: 45d11e51bb66c2deb63a006fe3953c4b6fbc50c2
commit-date: 2025-01-01
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.6

[Noratrieb]

Given that bpf-linker takes in LLVM IR, generating LLVM IR in a library seems correct

[workingjubilee]

@Noratrieb If we generate invalid LLVMIR for the target then any errors are deferred from the source crate until the linking step.

[Noratrieb]

yeah, just checking that we generate code for a library is not enough to verify our target promises for ebpf, but that's a problem with our tests, not with the target

[alessandrod]

The target intentionally generates bitcode, since the LLVM BPF target isn't capable of doing codegen of the whole libcore, so in bpf-linker we do LTO the stuff that doesn't codegen gets thrown away and then we emit bytecode.

I have ideas to fix this, but TBD whether the upstream LLVM maintainers will let me implement them 😅

[vadorovsky]

Reposting from #161141.

The main reasons why bpf-linker was created as a bitcode linker, were:

• Lack of support of >5 arguments in BPF calling convention. But that's fixed in LLVM 23.
• Necessity to perform fixups of debug info produced by Rust, so the Linux kernel accepts the BTF produced from DI produced by Rustc.
  • Some of them that are gone since LLVM 22-23:
    • Pointer types cannot carry a name. I fixed that in LLVM: [BPF] Do not emit names for PTR, CONST, VOLATILE and RESTRICT BTF types llvm/llvm-project#163174
    • Rust enums / variant parts were not supported. I also fixed that: [BPF] Support for DW_TAG_variant_part in BTF generation  llvm/llvm-project#155783
  • The only remaining one, and quite annoying one:
    • Non-C symbols in type names are not allowed (eg. < in Foo<u8>). Offending part of the Linux kernel: https://elixir.bootlin.com/linux/v7.1.8/source/kernel/bpf/btf.c#L880

I'm planning to send a patch fixing the last point some time soon, but we will still need some way of supporting the older kernels (at least to the oldest LTS of Ubuntu). I believe that one fixup can be done on a object fine, not necessarily on IR, so I was thinking about having some thin wrapper over GNU ld which would fix up the type names in BTF. Perhaps we could still keep it under the "bpf-linker" name (or perhaps something new, like "bpf-linker-ng"), but it would become compatible with the LD flavor, effectively fixing this issue. I would hope for getting this done around this autumn.

GNU ld is so far the only linker I know that supports BPF. Support in lld was once attempted, but didn't get accepted, perhaps good time to revive it soon. I was also thinking about adding support to wild.