On 9/9/21 3:45 PM, Jose E. Marchesi wrote:
Hi Yonghong.
LLVM14 added support for a new C attribute ([1])
__attribute__((btf_tag("arbitrary_str")))
This attribute will be emitted to dwarf ([2]) and pahole
will convert it to BTF. Or for bpf target, this
attribute will be emitted to BTF directly ([3]).
The attribute is intended to provide additional
information for
- struct/union type or struct/union member
- static/global variables
- static/global function or function parameter.
This new attribute can be used to add attributes
to kernel codes, e.g., pre- or post- conditions,
allow/deny info, or any other info in which only
the kernel is interested. Such attributes will
be processed by clang frontend and emitted to
dwarf, converting to BTF by pahole. Ultimiately
the verifier can use these information for
verification purpose.
The new attribute can also be used for bpf
programs, e.g., tagging with __user attributes
for function parameters, specifying global
function preconditions, etc. Such information
may help verifier to detect user program
bugs.
After this series, pahole dwarf->btf converter
will be enhanced to support new llvm tag
for btf_tag attribute. With pahole support,
we will then try to add a few real use case,
e.g., __user/__rcu tagging, allow/deny list,
some kernel function precondition, etc,
in the kernel.
We are looking into implementing this in the GCC BPF port.
Hi, Jose, thanks for your reply. It would be great if the
btf_tag can be implemented in gcc.
Supporting the new C attribute in BPF programs as a target-specific
attribute, and the new BTF kind, is straightforward enough.
However, I am afraid it will be difficult to upstream to GCC support for
a target-independent C attribute called `btf_tag' that emits a
LLVM-specific DWARF tag. Even if we proposed to use a GCC-specific
Are you concerned with the name? The btf_tag name cames from the
discussion in
https://lore.kernel.org/bpf/CAADnVQJa=b=hoMGU213wMxyZzycPEKjAPFArKNatbVe4FvzVUA@xxxxxxxxxxxxxx/
as llvm guys want this attribute to be explicitly referring to bpf echo
system because we didn't implement for C++, and we didn't try to
annotate everywhere. Since its main purpose is to eventually encode in
btf (for different architectures), so we settled with btf_tag instead of
bpf_tag.
But if you have suggestion to change to a different name which can
be acceptable by both gcc and llvm community, I am okay with that.
DWARF tag like DW_TAG_GNU_annotation using the same number, or better a
compiler neutral tag like DW_TAG_annotation or DW_TAG_BPF_annotation,
adding such an attribute for all targets would still likely to be much
controversial...
This is okay too. If gcc settles with DW_TAG_GNU_annotation with a
different number (not conflict with existing other llvm tag numbers),
I think llvm can change to have the same name and number since we are
still in the release.
Would you be open to explore other, more generic, ways to convey these
annotations to pahole, something that could be easily supported by GCC,
and potentially other C compilers?
Could you share your proposal in detail? I think some kind of difference
might be okay if it is handled by pahole and invisible to users,
although it would be good if pahole only needs to handle single
interface w.r.t. btf_tag support.
