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