[Pre-RFC] BTF relocations

[vad]

@anakryiko

It's actually quite common to have task->se.vruntime accesses in C BPF programs, so supporting this from the get go would be essential to make this useful for real-world applications.

Right. I'm not saying that accesses to structures nested by value are uncommon. What I'm saying is that we could roll out experimental nightly-only support for BTF relocations, behind a feature gate, without waiting for const Sized / sized hierarchy to be fully implemented.

That said, I agree that sized hierarchy and support for accesses nested by value would definitely be needed to expose the feature without a gate and on stable Rust.

@anakryiko

Re: naming. "preserve_access_index" naming we use in C is quite opaque and not very meaningful. Everyone just remembered and use it without asking questions, but I always felt like having it named as "btf_relocatable" or something along those lines ("relocatable" is the key here, IMO) would be best. Just my 2 cents on naming.

The more I think about it, the more I'm leaning towards neutral naming not tied to BTF, which could also suit Swift ABI or any other kind of field access relocation. My current implementation touches the field projection logic (compiler/rustc_codegen_ssa/src/mir/place.rs) in MIR in the following way:

compiler: Add support for BTF relocations for BPF targets

Choosing a target-specific name (bpf_*/btf_*) would mean poisoning this logic with target-specific concepts. It would also require add an another boolean if an another relocation mechanism (e.g. Swift ABI) is added.

Keeping the name neutral keeps MIR target-agnostic and adds only one boolean. Therefore, I would rather call it "relocatable".

@anakryiko

Oh, and I don't know if this is in scope or not, but it would be great to be able to express all of the libbpf/src/bpf_core_read.h at master · libbpf/libbpf · GitHub in Rust through whatever is the most natural way. Checks for type/field existence and enum value retrieval is critical for some real-world applications, not just relocatable field accesses.

Great suggestion. We could add the following Rust intrinsics, which would lower to the following LLVM intrinsics.

With neutral naming, this could eventually be implemented for other relocation mechanisms (e.g. Swift ABI):

• relocatable_type_id -> llvm.bpf.btf.type.id
• relocatable_compare -> llvm.bpf.compare
• relocatable_getelementptr_and_load -> llvm.bpf.getelementptr.and.load
• relocatable_getelementptr_and_store -> llvm.bpf.getelementptr.and.store
• relocatable_preserve_enum_value -> llvm.bpf.preserve.enum.value
• relocatable_preserve_field_info -> llvm.bpf.preserve.field.info
• relocatable_preserve_type_info -> llvm.bpf.preserve.type.info

The following intrinsics, which are of no use outside the BPF context, could carry BPF-specific names:

• bpf_load_byte -> llvm.bpf.load.byte
• bpf_load_half -> llvm.bpf.load.half
• bpf_load_word -> llvm.bpf.load.word

Furthermore, once size hierarchy is implemented, the offset_of! macro could lower to relocatable_preserve_field_info for relocatable types.