{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihs5hula5zl3j6wunatdx7fc56dux2l6j6y7awvlf5szfyemirlle",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkunhez5cgo2"
  },
  "path": "/t/pre-rfc-btf-relocations/24161?page=2#post_24",
  "publishedAt": "2026-05-02T11:21:00.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "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\nIn the end it doesn't matter all that much, but too-generic \"relocatable\" has a potential to be, well, too generic and thus confusing. But just my 2 cents.\n\nre: instrinsics, make sense and seems like a good idea. will the \"does it exist\" primitive be expressed as an extra argument to \"preserve_xxx_info\" or it would require its own set of intrinsics?",
  "title": "[Pre-RFC] BTF relocations"
}