From: Vineet Gupta <vineet.gupta@linux.dev>
To: Alan Maguire <alan.maguire@oracle.com>,
Emil Tsalapatis <emil@etsalapatis.com>,
dwarves@vger.kernel.org
Cc: bpf@vger.kernel.org, Andrii Nakryiko <andrii@kernel.org>,
acme@kernel.org, jose.marchesi@oracle.com,
David Faust <david.faust@oracle.com>,
Yonghong Song <yonghong.song@linux.dev>
Subject: Re: [PAHOLE v5 1/5] btf_loader: Handle decl tag component_idx for parameters
Date: Thu, 18 Jun 2026 10:18:21 -0700 [thread overview]
Message-ID: <a753dae1-6a4f-404c-aef5-e28cfc708f31@linux.dev> (raw)
In-Reply-To: <92447e74-7578-47cb-a08e-f6ca8a9e9274@oracle.com>
On 6/18/26 7:38 AM, Alan Maguire wrote:
> On 18/06/2026 05:46, Emil Tsalapatis wrote:
>> On Wed Jun 17, 2026 at 8:57 PM EDT, Vineet Gupta wrote:
>>> From: Alan Maguire <alan.maguire@oracle.com>
>>>
>>> A BTF_KIND_DECL_TAG with a non-negative component_idx applies to a
>>> specific function parameter (or struct/union member), not to the
>>> function itself. btf_loader.c however attached every decl tag to the
>>> type named by btf_type->type, so parameter decl tags were recorded on
>>> the function rather than on the parameter, and pfunct never printed
>>> them with the parameter.
>>>
>>> Resolve a non-negative component_idx to the corresponding parameter via
>>> new helpers ftype__parameter()/function__parameter(), and attach the
>>> tag there. Teach the pretty printer to emit a parameter's attributes by
>>> factoring the function-level attribute loop into tag__attributes_fprintf()
>>> and calling it from ftype__fprintf_parms() for each parameter.
>>>
>>> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
>>> Signed-off-by: Vineet Gupta <vineet.gupta@linux.dev>
>> With one nit:
>>
>> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
>>
>> (Also feel free to keep the tags for the other 3 patches since the
>> changes are minimal).
>>
>> </SNIP>
>>
>>> + if (component_idx >= 0) {
>>> + struct tag *func_tag = cu__function(cu, tp->type);
>>> +
>>> + if (func_tag != NULL) {
>>> + tag = function__parameter(tag__function(func_tag), cu,
>>> + component_idx);
>>> + if (tag == NULL) {
>>> + fprintf(stderr, "WARNING: BTF_KIND_DECL_TAG for unknown parameter %d in BTF id %d\n",
>>> + component_idx, tp->type);
>>> + return 0;
>>> + }
>>> + }
>>> + }
>>> +
>>> + if (tag == NULL && component_idx < 0)
>>> tag = cu__function(cu, tp->type);
>> Nit, I think this can be simplified as follows:
>>
>> tag = cu__function(cu, tp->type);
>> if (component_idx >= 0 && tag != NULL) {
>> tag = function__parameter(tag__function(tag), cu, component_idx);
>> if (tag == NULL) {
>> fprintf(stderr, "WARNING: BTF_KIND_DECL_TAG for unknown parameter %d in BTF id %d\n",
>> component_idx, tp->type);
>> return 0;
>> }
>> }
>>
>> <SNIP>
> yep, that looks good to me. if there are no other issues arising from this
> round and Vineet is happy with that change I can roll it in when landing this
> to save having to roll a v6.
Cool, works for me and and indeed it will be nice to avoid a v6 :-)
Thx,
-Vineet
>
> One other issue; we need to install bpftool for CI. I'm working on a change to
> support this (installing the version from the kernel tree), I'll try and get
> this in place ASAP. Thanks!
next prev parent reply other threads:[~2026-06-18 17:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-18 0:57 [PAHOLE v5 0/5] support for DW_TAG_GNU_annotation and fixes Vineet Gupta
2026-06-18 0:57 ` [PAHOLE v5 1/5] btf_loader: Handle decl tag component_idx for parameters Vineet Gupta
2026-06-18 4:46 ` Emil Tsalapatis
2026-06-18 13:27 ` Arnaldo Carvalho de Melo
2026-06-18 14:38 ` Alan Maguire
2026-06-18 17:18 ` Vineet Gupta [this message]
2026-06-18 0:57 ` [PAHOLE v5 2/5] dwarf_loader: Extract die__add_btf_type_tag() helper [NFC] Vineet Gupta
2026-06-18 0:57 ` [PAHOLE v5 3/5] dwarf_loader: Add support for DW_TAG_GNU_annotation Vineet Gupta
2026-06-18 0:57 ` [PAHOLE v5 4/5] tests: Support GCC in pfunct-btf-decl-tags test Vineet Gupta
2026-06-18 0:57 ` [PAHOLE v5 5/5] tests: Add btf_type_tag ordering test Vineet Gupta
2026-06-18 4:47 ` Emil Tsalapatis
2026-06-18 13:25 ` Arnaldo Carvalho de Melo
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=a753dae1-6a4f-404c-aef5-e28cfc708f31@linux.dev \
--to=vineet.gupta@linux.dev \
--cc=acme@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=david.faust@oracle.com \
--cc=dwarves@vger.kernel.org \
--cc=emil@etsalapatis.com \
--cc=jose.marchesi@oracle.com \
--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 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.