External Publication
Visit Post

[Pre-RFC] BTF relocations

Rust Internals [Unofficial] April 10, 2026
Source

vad:

Because the offset_of intrinsic is const:

pub const fn offset_of<T: PointeeSized>(variant: u32, field: u32) -> usize;

and I'm under the impression that we want to treat BTF-relocatable field access as non-const.

Presumably, the intrinsic would become conditionally const (leveraging https://github.com/rust-lang/rfcs/pull/3762).

vad:

It's not strictly necessary, because matching container type, its name and matching field name are sufficient for the relocation to work.

In one of the posts you linked, I see mention of version suffixes in the names, which are ignored for relocations. Should that mechanism work in Rust as well? (If not, then an alternative mechanism, e.g. attribute, is presumably necessary.)

vad:

Jules-Bertholet:

Is there any connection to/similarity with Swift stable ABI?

Not really. Actually I don't even think Rust ABI should be used for BTF relocatable types. #[repr(btf)] should enforce the C ABI, I'm going to update the RFC and examples accordingly.

To clarify the point I was driving at: Swift's ABI supports making limited changes to struct layouts while preserving compatibility, so it's conceptually similar to BTF relocations. I was wondering if any new syntax or high-level language APIs we add to support BTF relocations, could also be leveraged to support Swift interop—even if the backend implementation is very different.

vad:

But if the relocated access still stays within some valid memory region while pointing to the wrong field, then this can become a silent logic bug instead.

Logic bug, or UB?

Discussion in the ATmosphere

Loading comments...