Re: [PATCH bpf-next 0/5] BTF: arbitrary __attribute__ encoding

["Jose E. Marchesi" <jose.marchesi@oracle.com>]

> On Wed, Jan 22, 2025 at 3:44 AM Jose E. Marchesi
> <jose.marchesi@oracle.com> wrote:
>>
>>
>> > This patch series extends BPF Type Format (BTF) to support arbitrary
>> > __attribute__ encoding.
>> >
>> > Setting the kind_flag to 1 in BTF type tags and decl tags now changes
>> > the meaning for the encoded tag, in particular with respect to
>> > btf_dump in libbpf.
>> >
>> > If the kflag is set, then the string encoded by the tag represents the
>> > full attribute-list of an attribute specifier [1].
>>
>> Why is extending BTF necessary for this?  Type and declaration tags
>> contain arbitrary strings, and AFAIK you can have more than one type tag
>
> Because currently TYPE_TAG(some_string) is
> __attribute__((btf_type_tag("some_string"))).
>
> That btf_type_tag() attribute name is hard-coded in the semantics of
> current TYPE_TAG (and DECL_TAG as well). So here Ihor is generalizing
> this to be __attribute__((some_string)).
>
>> associated with a single type or declaration.  Why coupling the
>> interpretation of the contents of the string with the transport format?
>>
>> Something like "cattribute:always_inline".
>
> I think that ship has sailed. We didn't define any extra semantics for
> any sort of "prefix:" part of TYPE_TAG's string, and I'm not sure we
> want to retroactively define anything like that at this point.
>
> What is exactly the problem with using kflag=1? Keep in mind, at least
> initially, this is meant for tools like pahole and bpftool, not
> GCC/Clang itself, to augment BTF with extra annotations (like
> preserve_access_index attribute that is added when generating
> vmlinux.h).

Ah ok, I misunderstood how this is intended to be used.

I thought it would be the BPF compiler that would be creating these
entries.  But it is these tools that will emit the attributes in the
headers, and then augment the BTF entries for these particular
attributes when loading the programs that include the headers?

>
>>
>> > This feature will allow extending tools such as pahole and bpftool to
>> > capture and use more granular type information, and make it easier to
>> > manage compatibility between clang and gcc BPF compilers.
>> >
>> > [1] https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Attribute-Syntax.html
>> >
>> > Ihor Solodrai (5):
>> >   libbpf: introduce kflag for type_tags and decl_tags in BTF
>> >   libbpf: check the kflag of type tags in btf_dump
>> >   selftests/bpf: add a btf_dump test for type_tags
>> >   bpf: allow kind_flag for BTF type and decl tags
>> >   selftests/bpf: add a BTF verification test for kflagged type_tag
>> >
>> >  Documentation/bpf/btf.rst                     |  27 +++-
>> >  kernel/bpf/btf.c                              |   7 +-
>> >  tools/include/uapi/linux/btf.h                |   3 +-
>> >  tools/lib/bpf/btf.c                           |  87 +++++++---
>> >  tools/lib/bpf/btf.h                           |   3 +
>> >  tools/lib/bpf/btf_dump.c                      |   5 +-
>> >  tools/lib/bpf/libbpf.map                      |   2 +
>> >  tools/testing/selftests/bpf/prog_tests/btf.c  |  23 ++-
>> >  .../selftests/bpf/prog_tests/btf_dump.c       | 148 +++++++++++++-----
>> >  tools/testing/selftests/bpf/test_btf.h        |   6 +
>> >  10 files changed, 234 insertions(+), 77 deletions(-)