From: Yonghong Song <yonghong.song@linux.dev>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Alan Maguire <alan.maguire@oracle.com>,
Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
dwarves@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH dwarves v3 7/9] dwarf_loader: Handle expression lists
Date: Sun, 22 Mar 2026 11:33:59 -0700 [thread overview]
Message-ID: <52d00c7b-c98f-4812-878e-7e1cae3e09d2@linux.dev> (raw)
In-Reply-To: <ab8lUbZE83_XEyyR@krava>
On 3/21/26 4:10 PM, Jiri Olsa wrote:
> On Fri, Mar 20, 2026 at 12:09:53PM -0700, Yonghong Song wrote:
>
> SNIP
>
>> + if (byte_size <= cu->addr_size || !cu->agg_use_two_regs) {
>> + switch (expr[0].atom) {
>> + case DW_OP_reg0 ... DW_OP_reg31:
>> + if (loc_num != 0)
>> + break;
>> + *ret = expr[0].atom;
>> + if (*ret == expected_reg)
>> + return *ret;
>> + break;
>> + case DW_OP_breg0 ... DW_OP_breg31:
>> + if (loc_num != 0)
>> + break;
>> + bool has_op_stack_value = false;
>> + for (int i = 1; i < exprlen; i++) {
>> + if (expr[i].atom == DW_OP_stack_value) {
>> + has_op_stack_value = true;
>> + break;
>> + }
>> + }
>> + if (!has_op_stack_value)
>> + break;
>> + /* The existence of DW_OP_stack_value means that
>> + * DW_OP_bregX register is used as value.
>> + */
>> + *ret = expr[0].atom - DW_OP_breg0 + DW_OP_reg0;
>> + if (*ret == expected_reg)
>> + return *ret;
>> + }
>> + } else {
>> + /* cu->addr * 2 */
>> + int off = 0;
>> + for (int i = 0; i < exprlen; i++) {
>> + if (expr[i].atom == DW_OP_piece) {
>> + int num = expr[i].number;
>> + if (i == 0) {
>> + off = num;
>> + continue;
>> + }
>> + if (off < cu->addr_size) (*lower_half) |= (1 << off);
>> + else (*upper_half) |= (1 << (off - cu->addr_size));
>> + off += num;
> this is really hard for me to read.. I think it needs to follow common
> formatting rules and it deserves some explanation either in comments
> or in changelog
Okay, I will add comments to explain what it is.
>
>> + } else if (expr[i].atom >= DW_OP_reg0 && expr[i].atom <= DW_OP_reg31) {
>> + if (off < cu->addr_size)
>> + *ret = expr[i].atom;
>> + else if (*ret < 0)
>> + *ret = expr[i].atom;
>> + }
>> + /* FIXME: not handling DW_OP_bregX yet since we do not have
>> + * a use case for it yet for linux kernel.
>> + */
>> + }
>> + }
>> +
>> return PARM_CONTINUE;
>> }
>>
>> +/* The lower_half and upper_half, computed in parameter__multi_exprs(), are handled here.
>> + */
>> +static int parameter__handle_two_addr_len(int expected_reg, unsigned long lower_half, unsigned long upper_half,
>> + int ret, Dwarf_Die *die, struct conf_load *conf, struct cu *cu,
>> + struct parameter *parm) {
>> + if (!lower_half && !upper_half)
>> + return ret;
>> +
>> + if (ret != expected_reg)
>> + return ret;
>> +
>> + if (!conf->true_signature)
>> + return PARM_DEFAULT_FAIL;
>> +
>> + /* Both halfs are used based on dwarf */
>> + if (lower_half && upper_half)
>> + return PARM_TWO_ADDR_LEN;
>> +
>> + /* FIXME: parm->name may be NULL due to abstract origin. We do not want to
>> + * update abstract origin as the type in abstract origin may be used
>> + * in some other places. We could remove abstract origin in this parameter
>> + * and add name and type in parameter itself. Right now, for current bpf-next
>> + * repo, we do not have instances below where parm->name is NULL for x86_64 arch.
>> + */
>> + if (!parm->name)
>> + return PARM_TO_BE_IMPROVED;
>> +
>> + /* FIXME: Only support single field now so we can have a good parameter name and
>> + * type for it.
>> + */
>> + if (__builtin_popcountll(lower_half) >= 2 || __builtin_popcountll(upper_half) >= 2)
>> + return PARM_TO_BE_IMPROVED;
>> +
>> + int field_offset;
>> + if (__builtin_popcountll(lower_half) == 1)
>> + field_offset = __builtin_ctzll(lower_half);
>> + else
>> + field_offset = cu->addr_size + __builtin_ctzll(upper_half);
>> +
>> + /* FIXME: Only struct type is supported. */
>> + Dwarf_Die member_die;
>> + if (!get_member_with_offset(die, field_offset, &member_die))
>> + return PARM_TO_BE_IMPROVED;
>> +
>> + const char *member_name = attr_string(&member_die, DW_AT_name, conf);
>> + int len = sizeof(parm->name) + strlen(member_name) + 3;
> this seems wrong, shoud be strlen for parm->name? maybe asprintf is
> better option in here?
Thanks for spotting this. It should be strlen. asprintf is even better.
>
>> + char *new_name = malloc(len);
> also there's cu__malloc, and we should check if the allocation failed
Ack
>
>> + sprintf(new_name, "%s__%s", parm->name, member_name);
>> + parm->name = new_name;
> I wonder this will leak, because normally the name is allocated with
> dwarf_formstring and we don't need to free it, but now we do
This will leak. I thought the number of functions for this pattern
is limited. But nevertheless, leaking is not good.
I will wait a little bit for more reviews before sending version 4.
Thanks for review!
>
> jirka
next prev parent reply other threads:[~2026-03-22 18:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 19:09 [PATCH dwarves v3 0/9] pahole: Encode true signatures in kernel BTF Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 1/9] dwarf_loader: Reduce parameter checking with clang DW_AT_calling_convention attr Yonghong Song
2026-03-21 23:10 ` Jiri Olsa
2026-03-22 17:36 ` Yonghong Song
2026-03-23 12:56 ` Alan Maguire
2026-03-23 18:32 ` Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 2/9] dwarf_loader: Handle signatures with dead arguments Yonghong Song
2026-03-21 23:10 ` Jiri Olsa
2026-03-22 18:03 ` Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 3/9] dwarf_loader: Refactor initial ret -1 to be macro PARM_DEFAULT_FAIL Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 4/9] dwarf_laoder: Handle locations with DW_OP_fbreg Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 5/9] dwarf_loader: Change exprlen checking condition in parameter__reg() Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 6/9] dwarf_loader: Detect optimized parameters with locations having constant values Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 7/9] dwarf_loader: Handle expression lists Yonghong Song
2026-03-21 23:10 ` Jiri Olsa
2026-03-22 18:33 ` Yonghong Song [this message]
2026-03-20 19:09 ` [PATCH dwarves v3 8/9] btf_encoder: Handle optimized parameter properly Yonghong Song
2026-03-20 19:10 ` [PATCH dwarves v3 9/9] tests: Add a few clang true signature tests Yonghong Song
2026-03-23 15:41 ` Alan Maguire
2026-03-23 19:58 ` 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=52d00c7b-c98f-4812-878e-7e1cae3e09d2@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 \
--cc=olsajiri@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.