Re: [RFC PATCH v3 2/3] sparc64: Support PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER

[sashiko-bot@kernel.org]

> Select HAVE_PERF_REGS and HAVE_PERF_USER_STACK_DUMP and add the
> perf_regs implementation. The exposed registers mirror struct pt_regs:
> %g1-%g7, %o0-%o7 (named from the user's point of view; pt_regs calls
> them UREG_I*), %tstate, NPC and %y, with the PC in the slot of %g0, as
> mips and loongarch do for their hardwired-zero register. Trap entry
> does not save %g0, so its pt_regs slot holds stale stack contents for
> a trap taken in the kernel and must not be exposed.
> 
> %o6 is reported as held in the register, i.e. with the 2047 stack bias
> for a 64-bit stack, the same as ptrace and user_stack_pointer(). The
> stack dump starts at the stack's actual address instead, %o6 + 2047
> when test_thread_64bit_stack() says so, so that it begins at the
> sampled frame; the uapi header documents this for consumers.
> 
> User-mode values of a 32-bit task are truncated to 32 bits as
> genregs32_get() does, since the hardware does not zero-extend them.
> Kernel-mode registers, as seen by PERF_SAMPLE_REGS_INTR, are left
> alone.
> 
> perf_arch_prepare_ustack() flushes the user register windows so the
> sampled window's %l and %i registers are in the dumped stack, where a
> DWARF unwinder needs them: the CFI of a function after `save` defines
> the CFA in terms of %i6.
> 
> This makes perf record --call-graph dwarf and eu-stackprof usable on
> sparc64.
> 
> Signed-off-by: Stian Halseth <stian@itx.no>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923090429.2026529-1-stian@itx.no?part=2