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

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

Reproduce the command from the issue and inspect the generated .rcgu.o with llvm-dis. Compare the target's linker behavior with src/tools/llvm-bitcode-linker/src/bin/llvm-bitcode-linker.rs and the bpf-linker approach. Done means --target bpfel-unknown-none produces an eBPF object or fails clearly instead of silently producing LLVM bitcode.