All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Alan Maguire <alan.maguire@oracle.com>,
	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>
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 10:38:16 -0700	[thread overview]
Message-ID: <a8e31e06-8288-46c0-9f6c-9052e1d9707e@linux.dev> (raw)
In-Reply-To: <e4b680e7-5829-42c2-add1-f2b5199ff7b6@oracle.com>

On 9/17/26 3:30 AM, Alan Maguire wrote:
> On 17/09/2026 02:20, 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>
> 
> Small suggestion; while this test is great at exercising the btf dump
> internals, adding a bpftool btf dump test to prog_tests/bpftool_btf_dump.c
> might help illustrate the change end-to-end (if you're planning this
> as part of the work to eliminate the push/pop attributes feel free to
> ignore). Thanks!

Hi Alan. Thanks for taking a look.

Yes, that's exactly the plan. btf_dump.c contains tests for libbpf btf_dump
primitives, and bpftool_btf_dump.c is for bpftool format c.

So more tests coming soon, no worries.

> 
> 
>> ---
>>  .../selftests/bpf/prog_tests/btf_dump.c       | 343 +++++++++++++++++-
>>  1 file changed, 342 insertions(+), 1 deletion(-)
>>
>> [...]
>>  
> 


  reply	other threads:[~2026-09-17 17:38 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 [this message]
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=a8e31e06-8288-46c0-9f6c-9052e1d9707e@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=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --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.