From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Quentin Monnet <qmo@kernel.org>
Cc: bpf@vger.kernel.org, Alan Maguire <alan.maguire@oracle.com>,
Cupertino Miranda <cupertino.miranda@oracle.com>,
David Faust <david.faust@oss.qualcomm.com>,
Ian Rogers <irogers@google.com>,
"Jose E . Marchesi" <jose.marchesi@oracle.com>,
Vineet Gupta <vineet.gupta@linux.dev>,
Yonghong Song <yonghong.song@linux.dev>
Subject: [PATCH bpf-next v4 06/17] libbpf: Let decl tags override how btf_dump renders type tags
Date: Thu, 5 Nov 2026 10:58:34 -0700 [thread overview]
Message-ID: <20261105175845.30357-7-ihor.solodrai@linux.dev> (raw)
In-Reply-To: <20261105175845.30357-1-ihor.solodrai@linux.dev>
A tool that dumps C from kernel BTF may need a type tag printed
differently than btf_dump prints it by default, for example as a macro
that the generated header defines. The tool can't change the tag
itself: kernel BTF must keep the encoding the kernel expects, and if
the dumped BTF is the base of a split, a type in the base can't refer
to a type added to the split.
A decl tag annotates another type by referencing it, so a split can
attach one to a type tag of its base.
Let such decl tags override the rendering of the type tag: when a type
tag has decl tags with component_idx -1, print them in its place, the
same way as decl tags on declarations. The tool that builds the dumped
BTF then decides how each type tag is rendered.
The kernel rejects decl tags on type tags, so kernel BTF cannot have
any, and its C dumps are unchanged.
Document this in btf.rst.
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
---
Documentation/bpf/btf.rst | 10 ++++++++++
tools/lib/bpf/btf_dump.c | 12 ++++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
index 29de1222c3e7..ea0d699749af 100644
--- a/Documentation/bpf/btf.rst
+++ b/Documentation/bpf/btf.rst
@@ -511,6 +511,9 @@ representing the attribute-list of the attribute specifier. For
example, for an ``__attribute__((aligned(4)))`` the string's contents
is ``aligned(4)``.
+``btf_dump`` also accepts decl tags that reference a ``type_tag``, as
+described under ``BTF_KIND_TYPE_TAG``.
+
2.2.18 BTF_KIND_TYPE_TAG
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -542,6 +545,13 @@ If ``info.kind_flag`` is 1, then the type tag represents an arbitrary
__attribute__, and the ``name_off`` encodes a string representing the
attribute-list of the attribute specifier.
+``btf_dump`` prints decl tags that reference a type tag, with
+``btf_decl_tag.component_idx`` of ``-1``, in place of that type tag. They
+are printed the same way as decl tags on declarations. This lets a split
+BTF built for a C dump change how the type tags of its base BTF are
+printed, without modifying the base. The kernel rejects decl tags that
+reference type tags.
+
2.2.19 BTF_KIND_ENUM64
~~~~~~~~~~~~~~~~~~~~~~
diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c
index ad43bbd3b442..c12c3c248407 100644
--- a/tools/lib/bpf/btf_dump.c
+++ b/tools/lib/bpf/btf_dump.c
@@ -1033,10 +1033,11 @@ static void btf_dump_emit_decl_tag(struct btf_dump *d, const struct btf_type *t)
* tags of one type form a run that binary search finds the start of, in a
* fixed order so that the same BTF always renders the same C.
*/
-static void btf_dump_emit_decl_tags(struct btf_dump *d, __u32 id, int comp_idx)
+static int btf_dump_emit_decl_tags(struct btf_dump *d, __u32 id, int comp_idx)
{
size_t i, lo = 0, hi = d->decl_tag_cnt, mid;
const struct btf_type *t;
+ int cnt = 0;
/* lower bound on target_id */
while (lo < hi) {
@@ -1051,9 +1052,13 @@ static void btf_dump_emit_decl_tags(struct btf_dump *d, __u32 id, int comp_idx)
for (i = lo; i < d->decl_tag_cnt && d->decl_tags[i].target_id == id; i++) {
t = btf__type_by_id(d->btf, d->decl_tags[i].tag_id);
- if (btf_decl_tag(t)->component_idx == comp_idx)
+ if (btf_decl_tag(t)->component_idx == comp_idx) {
btf_dump_emit_decl_tag(d, t);
+ cnt++;
+ }
}
+
+ return cnt;
}
static void btf_dump_emit_struct_def(struct btf_dump *d,
@@ -1592,6 +1597,9 @@ static void btf_dump_emit_type_chain(struct btf_dump *d,
break;
case BTF_KIND_TYPE_TAG:
btf_dump_emit_mods(d, decls);
+ /* decl tags override the type tag, see btf.rst */
+ if (btf_dump_emit_decl_tags(d, id, -1))
+ break;
name = btf_name_of(d, t->name_off);
if (btf_kflag(t))
btf_dump_printf(d, " __attribute__((%s))", name);
--
2.56.0
next prev parent reply other threads:[~2026-11-05 17:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 17:58 [PATCH bpf-next v4 00/17] bpftool: Per-record CO-RE attributes in the C dump Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 01/17] Revert "libbpf: Render the arena type tag with its address space" Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 02/17] libbpf: Look up BTF strings without making BTF modifiable Ihor Solodrai
2026-11-05 18:41 ` bot+bpf-ci
2026-11-05 17:58 ` [PATCH bpf-next v4 03/17] bpftool: Dump C through a split BTF Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 04/17] selftests/bpf: Build BTF fixtures in btf_to_tmpfile() Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 05/17] selftests/bpf: Cover unknown BTF header-extension bytes in bpftool C dumps Ihor Solodrai
2026-11-05 17:58 ` Ihor Solodrai [this message]
2026-11-06 0:24 ` [PATCH bpf-next v4 06/17] libbpf: Let decl tags override how btf_dump renders type tags Andrii Nakryiko
2026-11-05 17:58 ` [PATCH bpf-next v4 07/17] libbpf, bpftool, resolve_btfids: Dump kflagged BTF tags as is Ihor Solodrai
2026-11-05 18:16 ` sashiko-bot
2026-11-06 0:25 ` Andrii Nakryiko
2026-11-05 17:58 ` [PATCH bpf-next v4 08/17] selftests/bpf: Cover type tag rendering overrides in btf_dump Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 09/17] selftests/bpf: Cover legacy arena type tags in bpftool C dumps Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 10/17] bpftool: Apply __bpf_relocatable per record on BTF dump Ihor Solodrai
2026-11-05 18:41 ` bot+bpf-ci
2026-11-05 17:58 ` [PATCH bpf-next v4 11/17] bpftool: Skip __bpf_relocatable on verifier-rewritten context types Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 12/17] bpftool: Emit __bpf_static_offset " Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 13/17] selftests/bpf: Cover record attributes in bpftool BTF dumps Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 14/17] selftests/bpf: Cover context and socket accesses through vmlinux.h Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 15/17] bpftool: Document __bpf_relocatable and __bpf_static_offset Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 16/17] bpftool: Render the arena type tag as __bpf_arena Ihor Solodrai
2026-11-05 17:58 ` [PATCH bpf-next v4 17/17] selftests/bpf: Cover the arena type tag in bpftool C dumps Ihor Solodrai
2026-11-06 0:30 ` [PATCH bpf-next v4 00/17] bpftool: Per-record CO-RE attributes in the C dump patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261105175845.30357-7-ihor.solodrai@linux.dev \
--to=ihor.solodrai@linux.dev \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cupertino.miranda@oracle.com \
--cc=daniel@iogearbox.net \
--cc=david.faust@oss.qualcomm.com \
--cc=eddyz87@gmail.com \
--cc=irogers@google.com \
--cc=jose.marchesi@oracle.com \
--cc=memxor@gmail.com \
--cc=qmo@kernel.org \
--cc=vineet.gupta@linux.dev \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox