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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 22, 2025 at 3:44 AM Jose E. Marchesi
<jose.marchesi@xxxxxxxxxx> 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).

>
> > 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(-)





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux