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