[cfe-dev] BPF: adding new clang extension bpf_dominating_decl attribute

Y Song via cfe-dev cfe-dev at lists.llvm.org
Mon Dec 20 16:06:08 PST 2021


This is a request to add a clang extention, more specificly,
a clang attribute named bpf_dominating_decl. This clang
extention is intended to be used for bpf target only. Below
I will explain in detail about this proposed attribute, why
bpf community needs this, how it will be used and other
aspects as described in https://clang.llvm.org/get_involved.html.

Evidence of a significant user community
========================================

We are proposing a new clang attribute bpf_dominating_decl which
was implemented in [1]. The feature has also been discussed in
cfe-dev mailing list ([2]). It intended to solve the
following use case:
  - A tool generated vmlinux.h is used for CO-RE (compile once,
    run everywhere) use cases.
  - vmlinux.h contains all kernel data structures for a particular config,
    see [3] and [4] about how it is generated and why it is important.
  - but vmlinux.h may have type conflicts with other headers
    user intends to use.

Macros are such an example. Currently CO-RE relocation cannot
handle macros and macros may be defined in some header files accessible
to the user. If those header files have type conflict with vmlinux.h,
users are forced to copy macro definitions. The same for some simple
static inline functions defined in header files. This issue has been
discussed before and that is why we proposed this issue. And just last
week, it is discussed/complained again ([5]) for not able to use
some non-kernel types with a header file which has some type conflicts
with vmlinux.h.

If it is accepted, the attribute will be used inside the vmlinux.h and
it will be used by virtually all bpf developers and it will make bpf devlopers
more productive by not copying macros, static inline functions or
non-kernel types.

A specific need to reside within the Clang tree
===============================================

The proposed attribute will be processed by Clang frontend lex and
sema and it would be
best to reside within the Clang tree.

A specification
===============

The bpf_dominating_decl attribute, as its name suggested, is a bpf target
specific attribute. The attribute is also for C language only.

The syntax:
   __attribute__((bpf_dominating_decl))
The attribute can be attached to:
   record, typedef and enum type declarations

If a type declaration is annotated with bpf_dominating_decl attribute,
that type declaration is considered as a dominating decl and later
any conflict declaration, compatible or not-compatible,
will be silently ignored.

The following is a simple example,

  #pragma clang attribute push(__attribute__((bpf_dominating_decl)), \
                               apply_to = any(record, enum, type_alias))
  typedef unsigned bob;
  #pragma clang attribute pop
  typedef int bob;

In the above example, the second typedef will not incur a compilation
error. The same for record types or enum values.

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

N/A

A long-term support plan
========================

The feature will be supported for ever.

A high-quality implementation
=============================

The feature has been implemented in [1] and has been code reviewed.
One thing not in [1] but in [1]'s comment is to link
bpf_dominating_decl attribute to CO-RE preserve_access_index attribute
in clang frontend. That is, a type is considered dominating only if
the type has both bpf_dominating_decl and preserve_access_index attributes.
We can amend the implementation with this if agreed upon.

A test suite
============

The [1] has implemented necessary tests for the feature.

References
==========
  [1] https://reviews.llvm.org/D111307
  [2] https://lists.llvm.org/pipermail/cfe-dev/2021-August/068696.html
  [3] https://www.grant.pizza/blog/vmlinux-header/
  [4] https://blog.aquasec.com/vmlinux.h-ebpf-programs
  [5] https://lore.kernel.org/bpf/CAEf4BzZ1K9uQ-K1Q2BCSBesR3RUj_NW8uHu6NduoX7uLBdfukQ@mail.gmail.com/


More information about the cfe-dev mailing list