BTF CO-RE relocations for the BPF target (preserve_access_index intrinsics)

Summary

The BPF target can't produce CO-RE-relocatable eBPF objects: rustc doesn't emit BTF field relocations (no Rust equivalent of clang's __builtin_preserve_access_index / the llvm.preserve.{struct,union}.access.index intrinsics). So a Rust eBPF program that reads kernel structs (task_struct, file, dentry, …) is pinned to the struct layout of the kernel it was built against, and silently breaks — or needs rebuilding — on any other kernel version.

I couldn't find an existing tracking issue on rust-lang/*; apologies if it's a duplicate — please point me at it. Filing to surface demand and ask where this should be driven.

Why it matters (concrete use case)

I'm building an open-source security tool with a BPF-LSM backend in Rust via aya. The data plane walks file/dentry/inode/task_struct for an in-kernel access decision. Because the object isn't CO-RE-relocatable, it runs only on its build kernel — an upgrade turns the security boundary into a silent no-op. The "compile once, run everywhere" model the eBPF ecosystem relies on isn't available to me in Rust, forcing workarounds (per-kernel rebuilds, or parsing the running kernel's BTF and injecting field offsets as .rodata constants). Recurring blocker — see aya-rs/aya#349 and LWN: "BTF, Rust, and the kernel toolchain".

State of the pieces

• LLVM — ready: llvm.preserve.struct.access.index etc. (D61810), used by clang.
• aya (loader) — ready: already parses .BTF.ext and applies CO-RE field relocations.
• rustc — the missing piece: no preserve_access_index intrinsics, no codegen to wrap GEPs / emit .BTF.ext.

A known design nuance

Unlike C, rustc may reorder fields unless #[repr(C)], so a Rust preserve_access_index must define which field identity a relocation refers to (raised by Jose Marchesi in the LWN discussion) — not a mechanical port of the clang builtin.

Ask

• Existing tracking issue / MCP / Zulip thread? Please link and close if so.
• If not — is rust-lang/rust right, or should this be a compiler-team MCP / internals thread?

I'm a downstream user, not a compiler expert, but happy to provide use cases, test against real workloads, or help where useful.

Start by reviewing the LLVM preserve.struct.access.index and related intrinsics cited in D61810, then compare them with clang's CO-RE behavior and aya's existing .BTF.ext relocation handling. Clarify the field-identity design for Rust layouts, identify the appropriate rust-lang tracking venue, and define completion around a decided design and compiler support for relocatable Rust eBPF objects.