| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20250318171557.GA2860028@e132581.arm.com>
Date: Tue, 18 Mar 2025 17:15:57 +0000
From: Leo Yan <leo.yan@....com>
To: Li Huafei <lihuafei1@...wei.com>
Cc: namhyung@...nel.org, acme@...nel.org, leo.yan@...ux.dev,
james.clark@...aro.org, mark.rutland@....com,
john.g.garry@...cle.com, will@...nel.org, irogers@...gle.com,
mike.leach@...aro.org, peterz@...radead.org, mingo@...hat.com,
alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
kjain@...ux.ibm.com, mhiramat@...nel.org,
atrajeev@...ux.vnet.ibm.com, sesse@...gle.com,
adrian.hunter@...el.com, kan.liang@...ux.intel.com,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 1/7] perf annotate: Handle arm64 load and store
instructions
Hi Huafei,
On Sat, Mar 15, 2025 at 12:21:31AM +0800, Li Huafei wrote:
> Add ldst_ops to handle load and store instructions in order to parse
> the data types and offsets associated with PMU events for memory access
> instructions. There are many variants of load and store instructions in
> ARM64, making it difficult to match all of these instruction names
> completely. Therefore, only the instruction prefixes are matched. The
> prefix 'ld|st' covers most of the memory access instructions, 'cas|swp'
> matches atomic instructions, and 'prf' matches memory prefetch
> instructions.
Thanks a lot for working on this!
> Signed-off-by: Li Huafei <lihuafei1@...wei.com>
> ---
> tools/perf/arch/arm64/annotate/instructions.c | 67 ++++++++++++++++++-
> 1 file changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/arch/arm64/annotate/instructions.c b/tools/perf/arch/arm64/annotate/instructions.c
> index d465d093e7eb..c212eb7341bd 100644
> --- a/tools/perf/arch/arm64/annotate/instructions.c
> +++ b/tools/perf/arch/arm64/annotate/instructions.c
> @@ -6,7 +6,8 @@
>
> struct arm64_annotate {
> regex_t call_insn,
> - jump_insn;
> + jump_insn,
> + ldst_insn; /* load and store instruction */
>
> };
>
> static int arm64_mov__parse(struct arch *arch __maybe_unused,
> @@ -67,6 +68,57 @@ static struct ins_ops arm64_mov_ops = {
> .scnprintf = mov__scnprintf,
> };
>
> +static int arm64_ldst__parse(struct arch *arch __maybe_unused,
> + struct ins_operands *ops,
> + struct map_symbol *ms __maybe_unused,
> + struct disasm_line *dl __maybe_unused)
> +{
> + char *s, *target;
> +
> + /*
> + * The part starting from the memory access annotation '[' is parsed
> + * as 'target', while the part before it is parsed as 'source'.
> + */
> + target = s = strchr(ops->raw, '[');
> + if (!s)
> + return -1;
I am wandering if this is sufficient for handling different load /
store instructions.
A simple case is an instruction "ldr x1, [x2]", the handling above
should can work well. How about instructions below with offsets:
ldr x2, [x0, #968]
ldr w3, [x25], #4
Could you also confirm if the parsing can fit the pattern for
load/store pair instructions?
ldp x29, x30, [sp], #16
The instruction loads paired 64-bit data into two registers.
> + while (s > ops->raw && *s != ',')
> + --s;
> +
> + if (s == ops->raw)
> + return -1;
> +
> + *s = '\0';
> + ops->source.raw = strdup(ops->raw);
>
> +
> + *s = ',';
> + if (!ops->source.raw)
> + return -1;
> +
> + ops->target.raw = strdup(target);
> + if (!ops->target.raw) {
> + zfree(ops->source.raw);
> + return -1;
> + }
> + ops->target.mem_ref = true;
> +
> + return 0;
> +}
> +
> +static int ldst__scnprintf(struct ins *ins, char *bf, size_t size,
> + struct ins_operands *ops, int max_ins_name)
> +{
> + return scnprintf(bf, size, "%-*s %s,%s", max_ins_name, ins->name,
> + ops->source.name ?: ops->source.raw,
> + ops->target.name ?: ops->target.raw);
> +}
> +
> +static struct ins_ops arm64_ldst_ops = {
> + .parse = arm64_ldst__parse,
> + .scnprintf = ldst__scnprintf,
> +};
> +
> static struct ins_ops *arm64__associate_instruction_ops(struct arch *arch, const char *name)
> {
> struct arm64_annotate *arm = arch->priv;
> @@ -77,6 +129,8 @@ static struct ins_ops *arm64__associate_instruction_ops(struct arch *arch, const
> ops = &jump_ops;
> else if (!regexec(&arm->call_insn, name, 2, match, 0))
> ops = &call_ops;
> + else if (!regexec(&arm->ldst_insn, name, 2, match, 0))
> + ops = &arm64_ldst_ops;
> else if (!strcmp(name, "ret"))
> ops = &ret_ops;
> else
> @@ -107,6 +161,15 @@ static int arm64__annotate_init(struct arch *arch, char *cpuid __maybe_unused)
> REG_EXTENDED);
> if (err)
> goto out_free_call;
> + /*
> + * The ARM64 architecture has many variants of load/store instructions.
> + * It is quite challenging to match all of them completely. Here, we
> + * only match the prefixes of these instructions.
> + */
> + err = regcomp(&arm->ldst_insn, "^(ld|st|cas|prf|swp)",
> + REG_EXTENDED);
As a first step, it is fine for me to support these memory types.
After I review the whole series, I might go back to check if we can
support other memory instructions (e.g. SVE, Memory Copy and
Memory Set instructions, etc). At least, we need to avoid any
barriers for extending these instructions.
Thanks,
Leo
> + if (err)
> + goto out_free_jump;
>
> arch->initialized = true;
> arch->priv = arm;
> @@ -117,6 +180,8 @@ static int arm64__annotate_init(struct arch *arch, char *cpuid __maybe_unused)
> arch->e_flags = 0;
> return 0;
>
> +out_free_jump:
> + regfree(&arm->jump_insn);
> out_free_call:
> regfree(&arm->call_insn);
> out_free_arm:
>
> --
> 2.25.1
>
Powered by blists - more mailing lists