From: Namhyung Kim <namhyung@kernel.org>
To: Tengda Wu <wutengda@huaweicloud.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
leo.yan@linux.dev, Li Huafei <lihuafei1@huawei.com>,
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 v2 16/16] perf annotate-arm64: Support 'mrs' instruction to track 'current' pointer
Date: Thu, 9 Apr 2026 23:52:35 -0700 [thread overview]
Message-ID: <adieMzY6o4yXGdFS@google.com> (raw)
In-Reply-To: <20260403094800.1418825-17-wutengda@huaweicloud.com>
On Fri, Apr 03, 2026 at 09:48:00AM +0000, Tengda Wu wrote:
> Extend update_insn_state() for arm64 to handle the 'mrs' instruction,
> enabling the tracking of the 'current' task pointer in the kernel.
>
> On arm64, the kernel uses the 'sp_el0' system register to store the
> address of the currently executing 'struct task_struct'. This is
> typically accessed via the 'get_current()' inline function, resulting
> in the instruction 'mrs xN, sp_el0'.
>
> To resolve the data type of the target register, first verify the
> access is to 'sp_el0' within a kernel DSO. Then, locate the
> 'get_current()' inline function's DWARF Die at the current PC and
> extract its return type (which is 'struct task_struct *').
>
> Introduce a global 'task_struct_off' cache to store the DWARF offset
> of this type. This is particularly important because the compiler-generated
> stack canary check code (which loads from 'current') often exists in
> code sections or leaf functions where the local Compilation Unit (CU)
> lacks a full 'struct task_struct' definition. Caching the offset allows
> 'perf annotate' to consistently resolve task-related fields across the
> entire kernel binary.
>
> A real-world example is shown below:
>
> ffff8000800deee8 <kthread_blkcg>:
> ffff8000800deef0: mrs x0, sp_el0 // x0 = current
> ffff8000800deef4: ldr w1, [x0, #44] // Access task_struct member
>
> Before this commit, the type flow starts with no information:
>
> chk [c] reg0 offset=0x2c ok=0 kind=0 cfa : no type information
> final result: no type information
>
> After this commit, the tracker identifies the 'current' pointer
> from the system register:
>
> mrs [8] sp_el0 -> reg0 type='struct task_struct*'
> chk [c] reg0 offset=0x2c ok=1 kind=1 (struct task_struct*) : Good!
> found by insn track: 0x2c(reg0) type-offset=0x2c
> final result: type='struct task_struct'
>
> Signed-off-by: Li Huafei <lihuafei1@huawei.com>
> Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
> ---
> .../perf/util/annotate-arch/annotate-arm64.c | 53 +++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/tools/perf/util/annotate-arch/annotate-arm64.c b/tools/perf/util/annotate-arch/annotate-arm64.c
> index 89b6b596f984..b03b12594260 100644
> --- a/tools/perf/util/annotate-arch/annotate-arm64.c
> +++ b/tools/perf/util/annotate-arch/annotate-arm64.c
> @@ -14,6 +14,7 @@
> #include "../debug.h"
> #include "../map.h"
> #include "../symbol.h"
> +#include "../dso.h"
>
> struct arch_arm64 {
> struct arch arch;
> @@ -289,6 +290,8 @@ static void adjust_reg_index_state(struct type_state *state, int reg,
> pr_debug_type_name(&tsr->type, tsr->kind);
> }
>
> +static Dwarf_Off task_struct_off;
> +
> static void update_insn_state_arm64(struct type_state *state,
> struct data_loc_info *dloc, Dwarf_Die *cu_die,
> struct disasm_line *dl)
> @@ -309,6 +312,56 @@ static void update_insn_state_arm64(struct type_state *state,
> sreg = src->reg1;
> dreg = dst->reg1;
>
> + if (!strcmp(dl->ins.name, "mrs")) {
> + Dwarf_Die func_die;
> + Dwarf_Attribute attr;
> + u64 ip, pc;
> +
> + if (!has_reg_type(state, sreg))
> + return;
> +
> + /* Handle case difference: LLVM (SP_EL0) vs objdump (sp_el0) */
> + if (!dso__kernel(map__dso(dloc->ms->map)) ||
> + strcasecmp(dl->ops.target.raw, "sp_el0"))
> + return;
> +
> + ip = dloc->ms->sym->start + dl->al.offset;
> + pc = map__rip_2objdump(dloc->ms->map, ip);
> +
> + if (!task_struct_off ||
> + !dwarf_offdie(dloc->di->dbg, task_struct_off, &type_die)) {
> + /*
> + * Find the inline function 'get_current()' Dwarf_Die
> + * and obtain its return value data type, which should
> + * be 'struct task_struct *'.
> + */
> + if (!die_find_inlinefunc(cu_die, pc, &func_die) ||
> + !dwarf_attr_integrate(&func_die, DW_AT_type, &attr) ||
> + !dwarf_formref_die(&attr, &type_die))
> + return;
I think it's better to verify if it's really the function and type we
want.
Thanks,
Namhyung
> +
> + /*
> + * Cache the 'struct task_struct *' die offset globally.
> + * This allows us to resolve stack canary accesses even
> + * in CUs that lack a full task_struct definition (e.g.,
> + * compiler-generated entry/exit code).
> + */
> + task_struct_off = dwarf_dieoffset(&type_die);
> + }
> +
> + tsr = &state->regs[sreg];
> + tsr->copied_from = -1;
> + tsr->type = type_die;
> + tsr->kind = TSR_KIND_TYPE;
> + tsr->offset = 0;
> + tsr->addr = 0;
> + tsr->ok = true;
> +
> + pr_debug_dtp("mrs [%x] sp_el0 -> reg%d", insn_offset, sreg);
> + pr_debug_type_name(&type_die, tsr->kind);
> + return;
> + }
> +
> if (!strcmp(dl->ins.name, "adrp")) {
> if (!has_reg_type(state, sreg) || !dl->ops.target.addr)
> return;
> --
> 2.34.1
>
next prev parent reply other threads:[~2026-04-10 6:52 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 9:47 [PATCH v2 00/16] perf arm64: Support data type profiling Tengda Wu
2026-04-03 9:47 ` [PATCH v2 01/16] perf llvm: Fix arm64 adrp instruction disassembly mismatch with objdump Tengda Wu
2026-04-03 9:47 ` [PATCH v2 02/16] perf capstone: Fix arm64 jump/adrp " Tengda Wu
2026-04-07 6:43 ` Namhyung Kim
2026-04-10 9:08 ` Tengda Wu
2026-04-03 9:47 ` [PATCH v2 03/16] perf annotate-arm64: Generalize arm64_mov__parse to support standard operands Tengda Wu
2026-04-07 6:58 ` Namhyung Kim
2026-04-03 9:47 ` [PATCH v2 04/16] perf annotate-arm64: Handle load and store instructions Tengda Wu
2026-04-07 7:09 ` Namhyung Kim
2026-04-03 9:47 ` [PATCH v2 05/16] perf annotate: Introduce extract_op_location callback for arch-specific parsing Tengda Wu
2026-04-03 9:47 ` [PATCH v2 06/16] perf dwarf-regs: Adapt get_dwarf_regnum() for arm64 Tengda Wu
2026-04-03 9:47 ` [PATCH v2 07/16] perf annotate-arm64: Implement extract_op_location() callback Tengda Wu
2026-04-07 7:26 ` Namhyung Kim
2026-04-03 9:47 ` [PATCH v2 08/16] perf annotate-arm64: Enable instruction tracking support Tengda Wu
2026-04-10 6:09 ` Namhyung Kim
2026-04-03 9:47 ` [PATCH v2 09/16] perf annotate-arm64: Support load instruction tracking Tengda Wu
2026-04-10 6:23 ` Namhyung Kim
2026-04-03 9:47 ` [PATCH v2 10/16] perf annotate-arm64: Support store " Tengda Wu
2026-04-03 9:47 ` [PATCH v2 11/16] perf annotate-arm64: Support stack variable tracking Tengda Wu
2026-04-10 6:29 ` Namhyung Kim
2026-04-03 9:47 ` [PATCH v2 12/16] perf annotate-arm64: Support 'mov' instruction tracking Tengda Wu
2026-04-10 6:39 ` Namhyung Kim
2026-04-03 9:47 ` [PATCH v2 13/16] perf annotate-arm64: Support 'add' " Tengda Wu
2026-04-10 6:42 ` Namhyung Kim
2026-04-03 9:47 ` [PATCH v2 14/16] perf annotate-arm64: Support 'adrp' instruction to track global variables Tengda Wu
2026-04-03 9:47 ` [PATCH v2 15/16] perf annotate-arm64: Support per-cpu variable access tracking Tengda Wu
2026-04-03 9:48 ` [PATCH v2 16/16] perf annotate-arm64: Support 'mrs' instruction to track 'current' pointer Tengda Wu
2026-04-10 6:52 ` Namhyung Kim [this message]
2026-04-07 6:31 ` [PATCH v2 00/16] perf arm64: Support data type profiling Namhyung Kim
2026-04-08 11:35 ` Tengda Wu
2026-04-10 7:00 ` Namhyung Kim
2026-04-10 8:17 ` 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=adieMzY6o4yXGdFS@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--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=nick.desaulniers+lkml@gmail.com \
--cc=peterz@infradead.org \
--cc=wutengda@huaweicloud.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