From: Tengda Wu <wutengda@huaweicloud.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Shuai Xue <xueshuai@linux.alibaba.com>,
james.clark@linaro.org, Li Huafei <lihuafei1@huawei.com>,
Peter Zijlstra <peterz@infradead.org>,
leo.yan@linux.dev, Ian Rogers <irogers@google.com>,
Kim Phillips <kim.phillips@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Bill Wendling <morbo@google.com>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Zecheng Li <zli94@ncsu.edu>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev
Subject: Re: [PATCH v4 20/23] perf annotate-arm64: Support 'add' instruction tracking
Date: Fri, 28 Aug 2026 15:41:30 +0800 [thread overview]
Message-ID: <fc22d702-9c53-415d-b3f2-8606daa2d656@huaweicloud.com> (raw)
In-Reply-To: <aoy-eAVaW_TsdymE@google.com>
On 2026/8/25 5:58, Namhyung Kim wrote:
> On Wed, Aug 19, 2026 at 11:04:36AM +0800, Tengda Wu wrote:
>>
>>
>> On 2026/8/11 16:45, Shuai Xue wrote:
>>>
>>>
>>> On 8/8/26 8:23 PM, Tengda Wu wrote:
>>>> Extend update_insn_state() for arm64 to track 'add' instructions for
>>>> structure member address calculation, which commonly appear as:
>>>>
>>>> add dreg, base, #offset
>>>> add dreg, base, reg2 (reg2 holds a constant)
>>>>
>>>> Unlike x86, the arm64 'add' instruction has an extra base register among
>>>> its source operands. Therefore, in terms of propagating the data type,
>>>> it is essentially performing a 'mov', except that before the 'mov', it
>>>> first needs to be updated by adding the offset or reg2.
>>>>
>>>> A real-world example is shown below:
>>>>
>>>> ffff80008001c9a8 <flush_ptrace_hw_breakpoint>:
>>>> ffff80008001c9c4: add x19, x0, #0xeb8 // x0 (task_struct*) + 0xeb8 -> x19
>>>> * ffff80008001c9d0: ldr x0, [x19]
>>>>
>>>> Before this commit, the type flow broke at the 'add' instruction,
>>>> leaving the subsequent load with no type information:
>>>>
>>>> chk [28] reg19 offset=0 ok=0 kind=0 cfa : no type information
>>>> final result: no type information
>>>>
>>>> After this commit, the tracker correctly follows the member address
>>>> calculation:
>>>>
>>>> var [0] reg0 offset 0 type='struct task_struct*'
>>>> add [1c] address of 0xeb8(reg0) -> reg19 type='struct task_struct*'
>>>> chk [28] reg19 offset=0 ok=1 kind=1 (struct task_struct*) : Good!
>>>> found by insn track: 0(reg19) type-offset=0xeb8
>>>> final result: type='struct task_struct'
>>>>
>>>> Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
>>>> ---
>>>> .../perf/util/annotate-arch/annotate-arm64.c | 87 ++++++++++++++++++-
>>>> 1 file changed, 85 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/tools/perf/util/annotate-arch/annotate-arm64.c b/tools/perf/util/annotate-arch/annotate-arm64.c
>>>> index 7b780bad8c07..eaeb4433fc3a 100644
>>>> --- a/tools/perf/util/annotate-arch/annotate-arm64.c
>>>> +++ b/tools/perf/util/annotate-arch/annotate-arm64.c
>>>> @@ -688,6 +688,87 @@ static void update_mov_insn_state(struct type_state *state,
>>>> pr_debug_type_name(&tsr->type, tsr->kind);
>>>> }
>>>> +static void update_add_insn_state(struct type_state *state,
>>>> + struct disasm_line *dl,
>>>> + struct annotated_op_loc *src,
>>>> + struct annotated_op_loc *dst)
>>>> +{
>>>> + struct type_state_reg *tsr;
>>>> + struct type_state_reg src_tsr;
>>>> + u32 insn_offset = dl->al.offset;
>>>> + int sreg = src->reg1;
>>>> + int dreg = dst->reg1;
>>>> + u64 imm_value;
>>>> +
>>>> + if (!has_reg_type(state, dreg))
>>>> + return;
>>>> +
>>>> + tsr = &state->regs[dreg];
>>>> + tsr->copied_from = -1;
>>>> +
>>>> +retry:
>>>> + if (!has_reg_type(state, sreg) || !state->regs[sreg].ok) {
>>>> + invalidate_reg_state(tsr);
>>>> + return;
>>>> + }
>>>> +
>>>> + src_tsr = state->regs[sreg];
>>>> +
>>>> + /*
>>>> + * Handle 'add' instructions of the form:
>>>> + * add dreg, base, #offset (immediate offset)
>>>> + * add dreg, base, reg2 (reg2 holds a constant)
>>>> + *
>>>> + * For case 2, retrieve the constant value from reg2
>>>> + * and use it as the offset.
>>>> + */
>>>> + imm_value = src->offset;
>>>> + if (src->multi_regs) {
>>>> + int reg2 = (sreg == src->reg1) ? src->reg2 : src->reg1;
>>>> +
>>>> + if (!has_reg_type(state, reg2) || !state->regs[reg2].ok) {
>>>> + /* Unable to resolve type for dst, bail out */
>>>> + invalidate_reg_state(tsr);
>>>> + return;
>>>> + }
>>>> + if (state->regs[reg2].kind == TSR_KIND_CONST)
>>>> + imm_value = state->regs[reg2].imm_value;
>>>
>>> First, when reg2 is valid but not TSR_KIND_CONST - say a pointer
>>> freshly loaded from memory - the addend is unknown at analysis time,
>>> yet imm_value silently stays 0 and propagation continues, tracking
>>> the destination as base + 0. Note the asymmetry: no state at all
>>> invalidates, but state that doesn't yield a value pretends the
>>> addend is zero. Unknown addend should invalidate as well:
>>>
>>> if (state->regs[reg2].kind != TSR_KIND_CONST) {
>>> invalidate_reg_state(tsr);
>>> return;
>>> }
>>>
>>
>> It might not be a direct invalidation, but rather swapping reg1/reg2 and
>> then retrying.
>>
>>> Second, the shifted/extended forms still break even with a constant
>>> reg2: extract_op_location_arm64() drops the "lsl #3" (or uxtw/sxtw)
>>> modifier, so add x0, x1, x2, lsl #3 contributes the unshifted value
>>> and maps later accesses to the wrong field. Maybe flag such operands
>>> during extraction (or fail the reg2 extraction) so the handler can
>>> skip them.
>>>
>>
>> Okay, so it seems shifted/extended forms are unavoidable. We may need to
>> introduce more fields into annotated_op_loc to record them, like this:
>>
>> diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
>> index 138d9258281c..b00e0ad96023 100644
>> --- a/tools/perf/util/annotate.h
>> +++ b/tools/perf/util/annotate.h
>> @@ -501,6 +501,8 @@ int arch__dwarf_regnum(const struct arch *arch, const char *str);
>> * @offset: Memory access offset in the operand
>> * @segment: Segment selector register
>> * @addr_mode: Addressing mode, only valid if @mem_ref is true
>> + * @extend_type: ARM64 register extend specifier (enum annotated_ext_type)
>> + * @shift: ARM64 shift amount (e.g., 0 to 4)
>> * @mem_ref: Whether the operand accesses memory
>> * @multi_regs: Whether the second register is used
>> * @imm: Whether the operand is an immediate value (in offset)
>> @@ -511,6 +513,8 @@ struct annotated_op_loc {
>> int offset;
>> u8 segment;
>> u8 addr_mode;
>> + u8 extend_type;
>> + u8 shift;
>> bool mem_ref;
>> bool multi_regs;
>> bool imm;
>> @@ -542,6 +546,19 @@ enum annotated_addr_mode {
>> PERF_ADDR_MODE_POST_INDEX,
>> };
>>
>> +enum annotated_ext_type {
>> + PERF_EXT_NONE = 0,
>> +
>> + PERF_EXT_UXTB,
>> + PERF_EXT_SXTB,
>> + PERF_EXT_UXTH,
>> + PERF_EXT_SXTH,
>> + PERF_EXT_UXTW,
>> + PERF_EXT_SXTW,
>> + PERF_EXT_UXTX, /* LSL is equivalent to UXTX */
This comment is inaccurate and will be removed.
>> + PERF_EXT_SXTX,
>> +};
>> +
>
> Looks ok to me. But more comments are needed for those who are not
> familiar with the arm64 ISA.
>
> Thanks,
> Namhyung
>
Got it. Will add more comments in v5.
Thanks,
Tengda
>
>> /**
>> * struct annotated_insn_loc - Location info of instruction
>> * @ops: Array of location info for source and target operands
>>
>>
>>>> + }
>>>> +
>>>> + if (src_tsr.kind == TSR_KIND_CONST) {
>>>> + tsr->kind = src_tsr.kind;
>>>> + tsr->imm_value = src_tsr.imm_value + imm_value;
>>>> + tsr->offset = 0;
>>>> + tsr->ok = src_tsr.ok;
>>>> +
>>>> + pr_debug_dtp("add [%x] imm %#"PRIx64"(reg%d) -> reg%d\n",
>>>> + insn_offset, imm_value, sreg, dreg);
>>>
>>> And since add is commutative, this early return drops the pointer
>>> side for add rd, const_reg, ptr_reg: sreg starts as reg1, hits the
>>> CONST case and returns before the goto retry at the bottom ever gets
>>> a chance to evaluate the pointer register. The result should be the
>>> pointer with the constant applied as an offset, not a plain constant.
>>> Maybe check the other register for a pointer type before falling into
>>> the CONST case (or move the CONST handling after the retry).
>>>
>>
>> Yeah, this issue is a side effect of the previous incomplete handling and
>> will be fixed together.
>>
>> Thanks,
>> Tengda
>>
next prev parent reply other threads:[~2026-08-28 7:41 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-08 12:23 [PATCH v4 00/23] perf arm64: Support data type profiling Tengda Wu
2026-08-08 12:23 ` [PATCH v4 01/23] perf capstone: Fix arm64 jump/adrp disassembly mismatch with objdump Tengda Wu
2026-08-10 13:08 ` Shuai Xue
2026-08-11 2:27 ` Tengda Wu
2026-08-11 3:25 ` Shuai Xue
2026-08-08 12:23 ` [PATCH v4 02/23] perf llvm: Fix arm64 adrp instruction " Tengda Wu
2026-08-08 12:23 ` [PATCH v4 03/23] perf annotate-arm64: Generalize arm64_mov__parse to support more instructions Tengda Wu
2026-08-08 12:23 ` [PATCH v4 04/23] perf annotate-arm64: Handle load and store instructions Tengda Wu
2026-08-08 12:23 ` [PATCH v4 05/23] perf dwarf-regs: Adapt get_dwarf_regnum() for arm64 Tengda Wu
2026-08-08 12:23 ` [PATCH v4 06/23] perf annotate: Adapt arch__dwarf_regnum() " Tengda Wu
2026-08-11 6:33 ` Shuai Xue
2026-08-11 8:16 ` Tengda Wu
2026-08-24 21:39 ` Namhyung Kim
2026-08-08 12:23 ` [PATCH v4 07/23] perf annotate: Introduce extract_op_location callback for arch-specific parsing Tengda Wu
2026-08-08 12:23 ` [PATCH v4 08/23] perf annotate-arm64: Implement extract_op_location() callback Tengda Wu
2026-08-11 6:50 ` Shuai Xue
2026-08-08 12:23 ` [PATCH v4 09/23] perf annotate: Deduplicate overlapping ARM SPE events for data type profiling Tengda Wu
2026-08-10 6:57 ` Adrian Hunter
2026-08-12 2:28 ` Tengda Wu
2026-08-12 6:07 ` Adrian Hunter
2026-08-12 8:53 ` Tengda Wu
2026-08-08 12:23 ` [PATCH v4 10/23] perf arm-spe: Set default synthesized event period to 1 Tengda Wu
2026-08-08 12:23 ` [PATCH v4 11/23] perf annotate-data: Extract invalidate_reg_state() as a common helper Tengda Wu
2026-08-11 7:09 ` Shuai Xue
2026-08-08 12:23 ` [PATCH v4 12/23] perf annotate-arm64: Enable instruction tracking support Tengda Wu
2026-08-08 12:23 ` [PATCH v4 13/23] perf annotate-arm64: Track return type after call instructions Tengda Wu
2026-08-08 12:23 ` [PATCH v4 14/23] perf annotate-arm64: Support load instruction tracking Tengda Wu
2026-08-11 7:36 ` Shuai Xue
2026-08-13 14:54 ` Tengda Wu
2026-08-24 21:44 ` Namhyung Kim
2026-08-08 12:23 ` [PATCH v4 15/23] perf annotate-arm64: Support store " Tengda Wu
2026-08-11 8:00 ` Shuai Xue
2026-08-14 1:26 ` Tengda Wu
2026-08-08 12:23 ` [PATCH v4 16/23] perf annotate-data: Expand type_state_reg imm_value to u64 Tengda Wu
2026-08-11 8:10 ` Shuai Xue
2026-08-14 7:58 ` Tengda Wu
2026-08-24 21:48 ` Namhyung Kim
2026-08-08 12:23 ` [PATCH v4 17/23] perf annotate-data: Track imm_value for stack variables Tengda Wu
2026-08-11 8:16 ` Shuai Xue
2026-08-08 12:23 ` [PATCH v4 18/23] perf annotate-arm64: Support stack variable tracking Tengda Wu
2026-08-11 8:24 ` Shuai Xue
2026-08-14 11:44 ` Tengda Wu
2026-08-08 12:23 ` [PATCH v4 19/23] perf annotate-arm64: Support 'mov' instruction tracking Tengda Wu
2026-08-11 8:37 ` Shuai Xue
2026-08-18 8:59 ` Tengda Wu
2026-08-08 12:23 ` [PATCH v4 20/23] perf annotate-arm64: Support 'add' " Tengda Wu
2026-08-11 8:45 ` Shuai Xue
2026-08-19 3:04 ` Tengda Wu
2026-08-24 21:58 ` Namhyung Kim
2026-08-28 7:41 ` Tengda Wu [this message]
2026-08-08 12:23 ` [PATCH v4 21/23] perf annotate-arm64: Support 'adrp' instruction to track global variables Tengda Wu
2026-08-11 8:50 ` Shuai Xue
2026-08-08 12:23 ` [PATCH v4 22/23] perf annotate-arm64: Support per-cpu variable access tracking Tengda Wu
2026-08-08 12:24 ` [PATCH v4 23/23] perf annotate-arm64: Support 'mrs' instruction to track 'current' pointer Tengda Wu
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=fc22d702-9c53-415d-b3f2-8606daa2d656@huaweicloud.com \
--to=wutengda@huaweicloud.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=kim.phillips@arm.com \
--cc=leo.yan@linux.dev \
--cc=lihuafei1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=namhyung@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=peterz@infradead.org \
--cc=xueshuai@linux.alibaba.com \
--cc=zli94@ncsu.edu \
/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