This is related to bpf CO-RE (compile once, run everythere) feature.
The feature has been implemented and merged in Clang. But per John's
suggestion, it is still good to give an explicit reasoning why this
Clang extension should be implemented. This can serve as a reference
point if people in the future wants to understand the reasoning or
touch the implementation and need to discuss. The format below
follows the suggestion in https://clang.llvm.org/get_involved.html.
Thank you for putting this information together and getting an RFC out!
Evidence of a significant user community
The CO-RE feature is to address the issue where the same bpf
program can run across different kernel versions. Note that
kernel internal data structures may change between different
kernel versions. A bpf program targetting one specific kernel
internal data structures often won't work for another kernel.
Before CO-RE, the general approach is bcc () where
the bpf program is recompiled for *each* kernel. This
incurs large binary size, significant run-time cost
and won't work in many environments (embedded system, container with
limited resource etc.).
CO-RE is proposed to address the above issue. Initial CO-RE patch
permits LLVM to generate relocations for struct/union member field access
and array index. But later as more use cases come up, CO-RE is
enhanced with relocations for field/type existence, type size, bitfield
handling and enum value etc. CO-RE permits the bpf program being compiled once
and then the ELF binary is processed by host bpfloader or host kernel with
properly adjusting kernel data structure accesses in the code based on
CO-RE has been implemented in LLVM and kernel () and currently
the feature is used virutally by every bpf developer. A few public
posts (, , ,  and ) are added here for reference.
A specific need to reside within the Clang tree
The CO-RE related builtin's and attributes are processed by clang
frontend. The relocation
information is preserved in IR and eventually the relocation is
generated by bpf target.
So CO-RE features are an integral part of the compiler so it is the best to have
feature within the Clang tree.
The CO-RE feature introduced a few clang extensions include:
. __builtin_preserve_access_index (initially added, )
. __builtin_preserve_field_info (added later, )
. __attribute__((preserve_access_index)) (added later, )
. __builtin_preserve_type_info (added later, )
. __builtin_preserve_enum_value (added later, )
All the above builtin's and attributes are used to record relocations.
are detailed specification:
type __builtin_preserve_access_index(type arg)
Any record member and array index accesses in the argument will
have relocations generated.
uint32_t __builtin_preserve_field_info(field_access, flag);
Depending on flag, the relocation is generated for (1) field size,
the field exists or not, (3) field signedness, or (4) certain bitfield
info. Specifically for the field existence case, if the field does not exist
in the actual host, the bpfloader will resolve the above builtin as return 0
to indicate the field doesn't exist so bpf verifier will skip this branch.
uint32_t __builtin_preserve_type_info(*(<type> *)0, flag);
Record a relocation for whether the "type" exists or not, or the
depending on the "flag".
Record a relocation for whether the "enum_value" (represented a enum name)
exists or not, or the enum value for the enum name, depending on "flag".
Currently this attribute can be applied to record. If a record has this
attribute, then any field access for this struct will generate a relocation.
The above builtin's and the attribute are the backbone of CO-RE feature.
Please refer to  for more detailed explanation.
Representation within the appropriate governing organization
What organization determines things like the specification you posted
above, or is there no organization behind these efforts?
A long-term support plan
The feature will be supported for ever.
This is not a long term support plan. When we have support needs
in the future, will there be people/a company/a community available to
do that work or is the expectation that once this lands, the Clang
community is responsible for it? (This matters with the above question
about the organization responsible for governing the specification --
can the Clang community do as they please here or do we need to
coordinate with others?)
A high-quality implementation
All the above builtin's and attributes are reviewed properly before merging.
Are there other implementations of CO-RE in the wild that we should be
A test suite
All new features are accompanied with necessary test cases.
Are there any external ways we can verify the functionality? (A
conformance suite, some other implementation we can test against, etc)