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 3/4] selftests/bpf: Test btf_dump rendering of decl_tags
Date: Thu, 17 Sep 2026 16:18:11 -0700 [thread overview]
Message-ID: <f52fa67478afad8ead28ff3be59dcd1c2590616a.camel@gmail.com> (raw)
In-Reply-To: <20260917012037.1396254-4-ihor.solodrai@linux.dev>
On Wed, 2026-09-16 at 18:20 -0700, Ihor Solodrai wrote:
> Cover the decl tag rendering the previous patch added. One subtest
> builds a BTF with every shape that renders, plus two that must not:
>
> - a named record with both forms of tag
> - a typedef'd anonymous record, whose attribute precedes the declarator
> - a union
> - a record that also carries the derived packed attribute
> - an anonymous record inlined at a member
> - two records whose tags are added in reverse target order, which is
> what pins the sort: without it the earlier record loses its attribute
> - attributes on a var and on a func, which btf_dump never declares
>
> A second subtest appends types and attributes to a dumper that has
> already run. Its last phase adds an attribute for a record emitted two
> dumps earlier and checks nothing is rendered for it: an attribute is
> part of the type, and btf_dump emits each definition once.
>
> A third covers members. A member attribute and a record one share a key
> in the index, so it checks they do not leak into each other's position,
> over a function pointer, an array and a bit-field - declarators the
> attribute has to follow rather than precede.
>
> A fourth covers typedefs, including a typedef of an anonymous record
> carrying three groups at once, binding to the member, the record and
> the typedef.
>
> Switch test_ctx__dump_and_compare() to compare_text_to_expected()
> while we are here.
>
> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> ---
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> .../selftests/bpf/prog_tests/btf_dump.c | 343 +++++++++++++++++-
> 1 file changed, 342 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/btf_dump.c b/tools/testing/selftests/bpf/prog_tests/btf_dump.c
> index fe04a955d46c..6c031e83dad3 100644
> --- a/tools/testing/selftests/bpf/prog_tests/btf_dump.c
> +++ b/tools/testing/selftests/bpf/prog_tests/btf_dump.c
> @@ -224,7 +224,12 @@ static void test_ctx__dump_and_compare(struct test_ctx *t,
> fflush(t->dump_buf_file);
> t->dump_buf[t->dump_buf_sz] = 0; /* some libc implementations don't do this */
>
> - ASSERT_STREQ(t->dump_buf, expected_output, message);
> + /*
> + * The mismatch has already been reported, so this only has to
> + * register the failure. ASSERT_OK() would append a stale errno to it.
> + */
> + err = compare_text_to_expected(t->dump_buf, expected_output);
> + ASSERT_EQ(err, 0, message);
Nit: Every caller of the compare_text_to_expected does such ASSERT,
let's embed the assert in the function and avoid the above comment.
...
> +/*
> + * btf_dump indexes decl attributes incrementally, only walking types appended
> + * since the last dump. Check that attributes on types added to an existing
> + * dumper are picked up, and that one added for a record that has already been
> + * emitted is not - btf_dump emits each definition once.
> + */
> +static void test_btf_dump_decl_tags_incremental(void)
Nit: I'd drop this test or made it a part of an existing one (w/o the s3 part).
...
next prev parent reply other threads:[~2026-09-17 23:18 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
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 [this message]
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=f52fa67478afad8ead28ff3be59dcd1c2590616a.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.