From: Yonghong Song <yonghong.song@linux.dev>
To: Alan Maguire <alan.maguire@oracle.com>,
Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
dwarves@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH dwarves 2/9] dwarf_loader: Handle signatures with dead arguments
Date: Fri, 20 Mar 2026 12:20:47 -0700 [thread overview]
Message-ID: <a212e256-234d-4320-be8d-3ddfcc2aa2e3@linux.dev> (raw)
In-Reply-To: <cc592002-b65b-4ec2-bc99-8a53ca221bbd@linux.dev>
On 3/19/26 10:00 PM, Yonghong Song wrote:
>
>
> On 3/19/26 11:55 AM, Alan Maguire wrote:
>> On 05/03/2026 22:55, Yonghong Song wrote:
>>> For llvm dwarf, the dead argument may be in the middle of
>>> DW_TAG_subprogram. So we introduce skip_idx in order to
>>> match expected registers properly.
>>>
>>> For example:
>>> 0x00042897: DW_TAG_subprogram
>>> DW_AT_name ("create_dev")
>>> DW_AT_calling_convention (DW_CC_nocall)
>>> DW_AT_type (0x0002429a "int")
>>> ...
>>>
>>> 0x000428ab: DW_TAG_formal_parameter
>>> DW_AT_name ("name")
>>> DW_AT_type (0x000242ed "char *")
>>> ...
>>>
>>> 0x000428b5: DW_TAG_formal_parameter
>>> DW_AT_location (indexed (0x3f) loclist =
>>> 0x000027f8:
>>> [0xffffffff87681370, 0xffffffff8768137a):
>>> DW_OP_reg5 RDI
>>> [0xffffffff8768137a, 0xffffffff87681392):
>>> DW_OP_reg3 RBX
>>> [0xffffffff87681392, 0xffffffff876813ae):
>>> DW_OP_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value)
>>> DW_AT_name ("dev")
>>> DW_AT_type (0x00026859 "dev_t")
>>> ...
>>>
>>> With skip_idx, we can identify that the second original argument
>>> 'dev' becomes the first one after optimization.
>>>
>>> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
>>> ---
>>> dwarf_loader.c | 27 +++++++++++++++++++++++----
>>> 1 file changed, 23 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/dwarf_loader.c b/dwarf_loader.c
>>> index 610b69e..1ced5e2 100644
>>> --- a/dwarf_loader.c
>>> +++ b/dwarf_loader.c
>>> @@ -1192,6 +1192,7 @@ static ptrdiff_t
>>> __dwarf_getlocations(Dwarf_Attribute *attr,
>>> struct func_info {
>>> bool signature_changed;
>>> + int skip_idx;
>>> };
>>> /* For DW_AT_location 'attr':
>>> @@ -1264,13 +1265,28 @@ static struct parameter
>>> *parameter__new(Dwarf_Die *die, struct cu *cu,
>>> if (parm != NULL) {
>>> bool has_const_value;
>>> Dwarf_Attribute attr;
>>> + int reg_idx;
>>> tag__init(&parm->tag, cu, die);
>>> parm->name = attr_string(die, DW_AT_name, conf);
>>> parm->idx = param_idx;
>>> - if (param_idx >= cu->nr_register_params || param_idx < 0)
>>> + if (param_idx < 0)
>>> return parm;
>>> - if (cu->producer_clang && !info->signature_changed)
>>> + if (!cu->producer_clang && param_idx >=
>>> cu->nr_register_params)
>>> + return parm;
>>> + if (cu->producer_clang) {
>>> + if (!info->signature_changed)
>>> + return parm;
>>> + /* if true_signature is not enabled, mark parameter as
>>> + * unexpected_reg since there is a skipped parameter
>>> before.
>>> + */
>>> + if (!conf->true_signature && info->skip_idx) {
>>> + parm->unexpected_reg = 1;
>>> + return parm;
>>> + }
>>> + }
>>> + reg_idx = param_idx - info->skip_idx;
>>> + if (reg_idx >= cu->nr_register_params)
>>> return parm;
>>> /* Parameters which use DW_AT_abstract_origin to point at
>>> * the original parameter definition (with no name in the
>>> DIE)
>>> @@ -1309,7 +1325,7 @@ static struct parameter
>>> *parameter__new(Dwarf_Die *die, struct cu *cu,
>>> parm->has_loc = dwarf_attr(die, DW_AT_location, &attr) !=
>>> NULL;
>>> if (parm->has_loc) {
>>> - int expected_reg = cu->register_params[param_idx];
>>> + int expected_reg = cu->register_params[reg_idx];
>>> int actual_reg = parameter__reg(&attr, expected_reg);
>>> if (actual_reg < 0)
>>> @@ -1322,8 +1338,11 @@ static struct parameter
>>> *parameter__new(Dwarf_Die *die, struct cu *cu,
>>> * contents.
>>> */
>>> parm->unexpected_reg = 1;
>>> - } else if (has_const_value) {
>>> + } else if (!cu->producer_clang && has_const_value) {
>>> + parm->optimized = 1;
>>> + } else if (cu->producer_clang) {
>>> parm->optimized = 1;
>>> + info->skip_idx++;
>>> }
>>> }
>> In [1] (dwarf_loader/btf_encoder: Detect reordered parameters)
>>
>> we detect reordered/missing parameters for gcc by comparing abstract
>> origin to concrete representation
>> and mark any such functions by setting the reordered_parm bitfield in
>> the encoder func state. In this
>> approach reordered encompasses both missing and actual reordering; in
>> practice it's always the former, but
>> the DWARF representation was confusing because it had the
>> actually-used parameters (with location info)
>> followed by the unused ones (without location info). Before the above
>> commit we were treating these
>> function signatures incorrectly as valid leading to wrong functions
>> signatures.
>>
>> All of this is to say: should we mark with reordered_parm instead?
>> The reason I suggest this is that
>> btf_encoder__save_func() has handling for skipping functions without
>> locations with reordered_parm set;
>> maybe we could find a way to unify that across clang/gcc cases?
>
> For v2, I focused on clang side. I have not studied such unification
> yet. I think it is possible
> since ultimately both clang and gcc tries to skip some parameters.
>
>>
>> Now in the clang case, I guess reordered is a poor description; for
>> gcc it really means "reordered as
>> compared to abstract origin". If we could find a better way to
>> describe/encompass both cases that would
>> be ideal I think. The terminology used in the gcc true signature code
>> isn't great today.
>
> Agree that we want *common* names to represent both gcc and clang for
> skipped parameters.
> BTW, please review v2 instead:
> https://lore.kernel.org/bpf/20260309153215.1917033-1-yonghong.song@linux.dev/
>
Jiri, Alan,
Thanks for the previous review. I just updated with v3:
https://lore.kernel.org/bpf/20260320190917.1970524-1-yonghong.song@linux.dev/
which addressed the issue to simplify getting cu->producer_clang, rewrite tests
based on latest convention, and try to use info->signature_changed instead of cu->producer_clang
to avoid clear separation between gcc and clang.
Please review v3.
Thanks!
>
> Thanks!
>
>>
>> [1]
>> https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=109e5e4554f663e5f12fb634bc54cceb710aec61
>
>
next prev parent reply other threads:[~2026-03-20 19:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-05 22:54 [PATCH dwarves 0/9] pahole: Encode true signatures in kernel BTF Yonghong Song
2026-03-05 22:55 ` [PATCH dwarves 1/9] dwarf_loader: Reduce parameter checking with clang DW_AT_calling_convention attr Yonghong Song
2026-03-19 12:32 ` Jiri Olsa
2026-03-19 17:31 ` Yonghong Song
2026-03-05 22:55 ` [PATCH dwarves 2/9] dwarf_loader: Handle signatures with dead arguments Yonghong Song
2026-03-19 18:55 ` Alan Maguire
2026-03-20 5:00 ` Yonghong Song
2026-03-20 19:20 ` Yonghong Song [this message]
2026-03-05 22:55 ` [PATCH dwarves 3/9] dwarf_loader: Refactor initial ret -1 to be macro PARM_DEFAULT_FAIL Yonghong Song
2026-03-05 22:55 ` [PATCH dwarves 4/9] dwarf_laoder: Handle locations with DW_OP_fbreg Yonghong Song
2026-03-05 22:55 ` [PATCH dwarves 5/9] dwarf_loader: Change exprlen checking condition in parameter__reg() Yonghong Song
2026-03-05 22:55 ` [PATCH dwarves 6/9] dwarf_loader: Detect optimized parameters with locations having constant values Yonghong Song
2026-03-05 22:55 ` [PATCH dwarves 7/9] dwarf_loader: Handle expression lists Yonghong Song
2026-03-05 22:55 ` [PATCH dwarves 8/9] btf_encoder: Handle optimized parameter properly Yonghong Song
2026-03-05 22:55 ` [PATCH dwarves 9/9] tests: Add a few clang true signature tests Yonghong Song
2026-03-19 18:48 ` Alan Maguire
2026-03-20 4:52 ` Yonghong Song
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=a212e256-234d-4320-be8d-3ddfcc2aa2e3@linux.dev \
--to=yonghong.song@linux.dev \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=arnaldo.melo@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dwarves@vger.kernel.org \
--cc=kernel-team@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox