From: Eduard Zingerman <eddyz87@gmail.com>
To: Ihor Solodrai <ihor.solodrai@linux.dev>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 2/4] libbpf: Render decl_tags in btf_dump
Date: Thu, 17 Sep 2026 15:46:24 -0700 [thread overview]
Message-ID: <77af8904cb6a4b3c0329b4de192b5045144567b8.camel@gmail.com> (raw)
In-Reply-To: <20260917012037.1396254-3-ihor.solodrai@linux.dev>
On Wed, 2026-09-16 at 18:20 -0700, Ihor Solodrai wrote:
> BTF_KIND_DECL_TAG is an attribute on a declaration: with kind_flag=0
> the tag name is the argument of a btf_decl_tag(), and with kind_flag=1
> it encodes a complete __attribute__.
>
> When doing btf_dump, render both forms at every declaration btf_dump
> emits - a record, a record member and a typedef:
>
> struct foo { ... } __attribute__((bar));
> struct foo { int a __attribute__((bar)); };
> typedef struct { ... } __attribute__((bar)) foo_t;
>
> A decl tag is a standalone type pointing at its target. Build an
> index of decl tags in btf_dump_resize(). Keep it as a flat array
> sorted by (target ID, tag ID). This allows for a stable emission order
> in btf_dump_emit_decl_tags(). Tag IDs are unique, so the comparison is
> a total order and qsort not being stable does not matter.
>
> Only composite and typedef targets are indexed. Valid BTF allows for
> decl_tags on many types, however btf_dump only supports records,
> record members and typedefs and ignores datasec, var and func.
>
> btf_dump_emit_decl_tags() binary searches for where the target's
> entries would begin and walks tags while the target matches. A record
> shares its target with its members, so the component_idx is matched
> there.
>
> A record attribute goes after the closing brace, where
> __attribute__((packed)) already goes. A member attribute goes after
> the bit-field width: clang rejects one between the declarator and the
> ':'. A typedef takes it after the declarator, so a typedef of an
> anonymous record can carry two groups at once, one binding to the
> record and one to the typedef.
>
> Every decl tag in vmlinux BTF is a bpf_kfunc or bpf_fastcall tag on a
> FUNC, which has no declaration in the C output, so generated vmlinux.h
> does not change.
>
> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> ---
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> @@ -962,6 +1011,47 @@ static void btf_dump_emit_struct_fwd(struct btf_dump *d, __u32 id,
> btf_dump_type_name(d, id));
> }
>
> +static void btf_dump_emit_decl_tag(struct btf_dump *d, const struct btf_type *t)
> +{
> + const char *name = btf_name_of(d, t->name_off);
> +
> + if (btf_kflag(t))
> + btf_dump_printf(d, " __attribute__((%s))", name);
> + else
> + btf_dump_printf(d, " __attribute__((btf_decl_tag(\"%s\")))", name);
> +}
> +
> +/*
> + * btf_dump_resize() keeps d->decl_tags sorted by (target ID, tag ID), so the
> + * 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.
> + *
--- 8< ---
> + * component_idx is not stored in d->decl_tags: a record and its members share
> + * a target ID, so it is read from each tag.
Nit: useless detail, obvious from the code.
--- >8 ---
...
> @@ -1007,6 +1097,8 @@ static void btf_dump_emit_struct_def(struct btf_dump *d,
> prev_bitfield = false;
> }
>
> + /* after the bit-field width; an attribute cannot precede it */
Nit: /* after the bit-field width */ ?
> + btf_dump_emit_decl_tags(d, id, i);
> btf_dump_printf(d, ";");
> }
>
...
next prev parent reply other threads:[~2026-09-17 22:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 1:20 [PATCH bpf-next v1 0/4] libbpf: Render decl_tags in btf_dump Ihor Solodrai
2026-09-17 1:20 ` [PATCH bpf-next v1 1/4] libbpf: Walk types in btf_dump_resize(), not in mark_referenced() Ihor Solodrai
2026-09-17 22:32 ` Eduard Zingerman
2026-09-17 1:20 ` [PATCH bpf-next v1 2/4] libbpf: Render decl_tags in btf_dump Ihor Solodrai
2026-09-17 1:30 ` sashiko-bot
2026-09-17 2:12 ` Alexei Starovoitov
2026-09-17 3:25 ` Ihor Solodrai
2026-09-17 22:46 ` Eduard Zingerman [this message]
2026-09-17 23:59 ` Andrii Nakryiko
2026-09-22 16:59 ` Ihor Solodrai
2026-09-22 19:43 ` Andrii Nakryiko
2026-09-17 1:20 ` [PATCH bpf-next v1 3/4] selftests/bpf: Test btf_dump rendering of decl_tags Ihor Solodrai
2026-09-17 10:30 ` Alan Maguire
2026-09-17 17:38 ` Ihor Solodrai
2026-09-17 23:18 ` Eduard Zingerman
2026-09-17 1:20 ` [PATCH bpf-next v1 4/4] selftests/bpf: Show the tag kflag in the raw BTF dump helper Ihor Solodrai
2026-09-17 1:27 ` sashiko-bot
2026-09-17 23:21 ` Eduard Zingerman
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=77af8904cb6a4b3c0329b4de192b5045144567b8.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=ihor.solodrai@linux.dev \
--cc=memxor@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.