[cfe-dev] Adding clang extension support for BPF CO-RE relocation support

[John McCall via cfe-dev]

On 20 Dec 2021, at 19:00, Y Song wrote:
> 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.

Thanks for making this post.

> 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 ([1]) 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
> relocation information.
>
> CO-RE has been implemented in LLVM and kernel ([2]) and currently
> the feature is used virutally by every bpf developer.

Thanks, this is very helpful.

> A specification
> ===============
>
> The CO-RE feature introduced a few clang extensions include:
>   . __builtin_preserve_access_index (initially added, [8])
>   . __builtin_preserve_field_info (added later, [9])
>   . __attribute__((preserve_access_index)) (added later, [10])
>   . __builtin_preserve_type_info (added later, [11])
>   . __builtin_preserve_enum_value (added later, [11])

Well, I wish we’d gone through this process earlier, because I really
don’t love a lot of the language design decisions here, starting from
the apparent claiming of “preserve” as the language feature prefix.
But I guess what’s done is done.

> Representation within the appropriate governing organization
> ============================================================

I’ll take any comments about these sections over to Aaron’s
part of the thread.

John.