{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigrcv2ehkeymn3yyw6yom7gyhcbjgokqwnvd4tdscx2gem6jo4ine",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mn5dyhhg4ax2"
  },
  "path": "/t/pre-rfc-btf-relocations/24161?page=2#post_26",
  "publishedAt": "2026-05-31T08:29:28.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "github.com/rust-lang/rfcs",
    "BTF relocations (#3966)",
    "vadorovsky",
    "+379\n-0",
    "…"
  ],
  "textContent": "anakryiko:\n\n> re: \"relocatable\". I would definitely not call it \"bpf_relocatable\" (target specific), but between \"relocatable\" and \"btf_relocatable\", BTF is the means through which relocation information is captured (BTF types/fields) and expressed (.BTF.ext section), so btf_ prefix seems appropriate. For this Swift use case you were talking about, would relocation information be expressed differently somehow?\n\nAfter giving it more thought, I think that `btf_` prefix definitely makes sense for intrinsics. I don't expect intrinsics to be shared between different types of field relocations (e.g. BTF, Swift).\n\nSo the intrinsics I proposed above could be called:\n\n\n    pub fn btf_field_byte_offset<T: PointeeSized>(variant: usize, field: usize) -> usize\n    pub fn btf_field_byte_size<T: PointeeSized>(variant: usize, field: usize) -> usize\n    pub fn btf_field_exists<T: PointeeSized>(variant: usize, field: usize) -> bool\n\n\nField projection is where a more unified design could make more sense though.\n\nvad:\n\n> With BTF-relocatable types, we are not sure whether a field exists during a runtime. Therefore, a field access does not provide any guarantees of soundess. That goes against Rust's guarantees of safety.\n\nI take this point back - BPF verifier will always reject programs with field accesses to non-existing fields, so the field projection is still safe. That said, I think it makes sense to start only with intrinsics now, and leave the field projection topic for future.\n\nGiven that there are no objections to the feature itself, I went ahead and submitted an RFC, trimmed down only to intrinsics, on GitHub:\n\ngithub.com/rust-lang/rfcs\n\n####  BTF relocations (#3966)\n\n`master` ← `vadorovsky:btf-relocations`\n\nopened 08:16AM - 31 May 26 UTC\n\n\n\n            vadorovsky\n          \n\n\n+379\n-0\n\n\nThe RFC proposes the `btf_relocatable_types` feature gate, that provides a `#[re…pr(btf)]` representation and low-level field-info intrinsics that emit [BTF (BPF TypeFormat)][btf] [CO-RE (Compile Once, Run Everywhere)][co-re] relocations. It also documents the relationship to `offset_of!`, ordinary field projection and LLVM BPF lowering. This feature was originally proposed as [pre-RFC][pre-rfc]. [btf]: https://docs.kernel.org/bpf/btf.html [co-re]: https://nakryiko.com/posts/bpf-portability-and-co-re/ [pre-rfc]: https://internals.rust-lang.org/t/pre-rfc-btf-relocations/24161/25 [Rendered](https://github.com/vadorovsky/rfcs/blob/btf-relocations/text/0000-btf-relocations.md)",
  "title": "[Pre-RFC] BTF relocations"
}