{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig434mpzr244nyis2hs3n3c6ldfzqpnwqgcrf5zd6g5iu3gidubqi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mj4q63f7sxa2"
  },
  "path": "/t/pre-rfc-btf-relocations/24161#post_3",
  "publishedAt": "2026-04-09T23:27:55.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "offset_of!"
  ],
  "textContent": "A couple of thoughts.\n\nFirst, this is, in effect, about changing Rust's type layout algorithms in order to place the fields at the same offsets that the Linux kernel would place them. As such, I'm wondering whether the new attribute should be `#[repr(btf)]`, given that it's mutually exclusive with other `repr` attributes and has the same purpose of changing where in a `struct` its data is stored.\n\nThe other thought is to wonder about the interaction of this with compile-time introspection. For example, macros like offset_of! normally assume that the offset of a field within a `struct` is known at compile time, whereas if it's being specified by relocations, that is not the case. There are existing exceptions where a field offset might not be known at compile time (e.g. a `#[repr(C)]` `struct` containing a `u8` and a `dyn Trait` can't determine the offset of its second field because it depends on its alignment, which for `dyn Trait` can vary at runtime); but all the existing exceptions are for unsized types. Should that imply that BTF types should not be `Sized`? (Thinking about it, they are logically un`Sized` because the size may change after the compile has already happened, due to the relocations, and thus the size is not known at compile time.)",
  "title": "[Pre-RFC] BTF relocations"
}