All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tengda Wu" <wutengda@huaweicloud.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v5 21/26] perf annotate-arm64: Support stack variable tracking
Date: Tue, 08 Sep 2026 13:36:27 +0000	[thread overview]
Message-ID: <20260908133633.666091F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <ddc32af9368f031ed716cf86b50a8bce79e87796.1788872630.git.wutengda@huaweicloud.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Invalid register comparison causes unparsed operands to be falsely treated as stack variables.
--

commit 7ef0e34126bb69c05756eba7378c5775c6ea2fd3
Author: Tengda Wu <wutengda@huaweicloud.com>

perf annotate-arm64: Support stack variable tracking

This commit extends update_insn_state_arm64 to track data types stored on the
stack. It handles stack loads and stores, introducing
propagate_store_reg_state to follow data types between registers and memory.

> diff --git a/tools/perf/util/annotate-arch/annotate-arm64.c b/tools/perf/util/annotate-arch/annotate-arm64.c
> index 9d43e2c2041cd..d520975c59363 100644
> --- a/tools/perf/util/annotate-arch/annotate-arm64.c
> +++ b/tools/perf/util/annotate-arch/annotate-arm64.c
> @@ -542,12 +544,57 @@ static int propagate_load_reg_state(struct type_state *state,

[ ... ]

> +	if (dloc->fb_cfa) {
> +		u64 ip = dloc->ms->sym->start + dl->al.offset;
> +		u64 pc = map__rip_2objdump(dloc->ms->map, ip);
> +
> +		if (die_get_cfa(dloc->di->dbg, pc, &fbreg, &fboff) < 0)
> +			fbreg = -1;
> +	}
> +
>  retry:
>  	if (arch_get_reg_offset(dloc->arch, src, sreg, state, false, &reg_offset))
>  		return -1;
>  
>  	reg_offset += mem_offset;
>  
> +	/* Check stack variables with offset */
> +	if (sreg == fbreg || sreg == state->stack_reg) {

[Severity: Medium]
When an unparsed or unsupported base register leaves sreg as -1, and fbreg is
also -1, does this condition evaluate to true? Could this cause unparsed
source operands to be incorrectly treated as stack loads?

[ ... ]

> +static void propagate_store_reg_state(struct type_state *state,
> +				      struct data_loc_info *dloc,
> +				      struct disasm_line *dl, int sreg,
> +				      struct annotated_op_loc *dst,
> +				      int mem_offset)
> +{

[ ... ]

> +	if (dloc->fb_cfa) {
> +		u64 ip = dloc->ms->sym->start + dl->al.offset;
> +		u64 pc = map__rip_2objdump(dloc->ms->map, ip);
> +
> +		if (die_get_cfa(dloc->di->dbg, pc, &fbreg, &fboff) < 0)
> +			fbreg = -1;
> +	}
> +
> +	/* Check stack variables with offset */
> +	if (dreg == fbreg || dreg == state->stack_reg) {

[Severity: Medium]
Similarly to the load case, if the base register extraction leaves dreg as -1
and fbreg is also -1, does this check evaluate to true? Will this erroneously
treat unparsed target operands as stack stores, potentially corrupting the
stack type state tracking?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1788872630.git.wutengda@huaweicloud.com?part=21

  reply	other threads:[~2026-09-08 13:36 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 13:05 [PATCH v5 00/26] perf arm64: Support data type profiling Tengda Wu
2026-09-08 13:05 ` [PATCH v5 01/26] perf capstone: Symbolize address operands to match objdump on arm64 Tengda Wu
2026-09-08 13:18   ` sashiko-bot
2026-09-09 14:49     ` Namhyung Kim
2026-09-10  7:38       ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 02/26] perf llvm: Fix arm64 adrp instruction disassembly mismatch with objdump Tengda Wu
2026-09-08 13:16   ` sashiko-bot
2026-09-09 14:50   ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 03/26] perf annotate-arm64: Generalize arm64_mov__parse to support more instructions Tengda Wu
2026-09-08 13:15   ` sashiko-bot
2026-09-09 14:52   ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 04/26] perf annotate-arm64: Handle load and store instructions Tengda Wu
2026-09-08 13:15   ` sashiko-bot
2026-09-09 14:58   ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 05/26] perf annotate: Normalize arch__dwarf_regnum() error return values Tengda Wu
2026-09-08 13:24   ` sashiko-bot
2026-09-08 17:57   ` Ian Rogers
2026-09-09 15:00     ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 06/26] perf annotate: Introduce extract_op_location callback for arch-specific parsing Tengda Wu
2026-09-08 13:20   ` sashiko-bot
2026-09-09 15:01   ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 07/26] perf dwarf-regs: Adapt get_dwarf_regnum() for arm64 Tengda Wu
2026-09-08 13:21   ` sashiko-bot
2026-09-09 15:03     ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 08/26] perf annotate: Adapt arch__dwarf_regnum() " Tengda Wu
2026-09-08 13:15   ` sashiko-bot
2026-09-09 15:04   ` Namhyung Kim
2026-09-08 13:05 ` [PATCH v5 09/26] perf annotate-arm64: Implement extract_op_location() callback Tengda Wu
2026-09-08 13:18   ` sashiko-bot
2026-09-10  8:49     ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 10/26] perf annotate: Default to --itrace=i1i for data type profiling Tengda Wu
2026-09-08 13:15   ` sashiko-bot
2026-09-09 15:38   ` Adrian Hunter
2026-09-08 13:05 ` [PATCH v5 11/26] perf arm-spe: Set default synthesized event period to 1 Tengda Wu
2026-09-08 13:12   ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 12/26] perf annotate-data: Extract invalidate_reg_state() as a common helper Tengda Wu
2026-09-08 13:11   ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 13/26] perf annotate-arm64: Enable instruction tracking support Tengda Wu
2026-09-08 13:18   ` sashiko-bot
2026-09-10  9:20     ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 14/26] perf annotate-data: Add arch_get_reg_offset helper Tengda Wu
2026-09-08 13:22   ` sashiko-bot
2026-09-10 12:13     ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 15/26] perf annotate-arm64: Track return type after call instructions Tengda Wu
2026-09-08 13:14   ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 16/26] perf annotate-arm64: Support load instruction tracking Tengda Wu
2026-09-08 13:23   ` sashiko-bot
2026-09-10 13:19     ` Tengda Wu
2026-09-10 13:28   ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 17/26] perf annotate-arm64: Support store " Tengda Wu
2026-09-08 13:22   ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 18/26] perf annotate-data: Expand type_state_reg imm_value to u64 Tengda Wu
2026-09-08 13:26   ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 19/26] perf annotate-data: Track imm_value for stack variables Tengda Wu
2026-09-08 13:29   ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 20/26] perf annotate-x86: Delete stale stack state on store of untracked register Tengda Wu
2026-09-08 13:20   ` sashiko-bot
2026-09-08 13:05 ` [PATCH v5 21/26] perf annotate-arm64: Support stack variable tracking Tengda Wu
2026-09-08 13:36   ` sashiko-bot [this message]
2026-09-11  1:41     ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 22/26] perf annotate-arm64: Support 'mov' instruction tracking Tengda Wu
2026-09-08 13:27   ` sashiko-bot
2026-09-11  2:22     ` Tengda Wu
2026-09-08 13:05 ` [PATCH v5 23/26] perf annotate-arm64: Support 'add' " Tengda Wu
2026-09-08 13:27   ` sashiko-bot
2026-09-11  2:29     ` Tengda Wu
2026-09-08 13:06 ` [PATCH v5 24/26] perf annotate-arm64: Support 'adrp' instruction to track global variables Tengda Wu
2026-09-08 13:26   ` sashiko-bot
2026-09-08 13:06 ` [PATCH v5 25/26] perf annotate-arm64: Support per-cpu variable access tracking Tengda Wu
2026-09-08 13:30   ` sashiko-bot
2026-09-11 10:15     ` Tengda Wu
2026-09-08 13:06 ` [PATCH v5 26/26] perf annotate-arm64: Support 'mrs' instruction to track 'current' pointer Tengda Wu
2026-09-08 13:31   ` sashiko-bot
  -- strict thread matches above, loose matches on Subject: below --
2026-09-08 13:00 [PATCH v5 00/26] perf arm64: Support data type profiling Tengda Wu
2026-09-08 13:01 ` [PATCH v5 21/26] perf annotate-arm64: Support stack variable tracking 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=20260908133633.666091F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wutengda@huaweicloud.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.