Re: [RFC PATCH 0/2] perf: user stack dump on sparc64 needs an arch hook

[Magnus Lindholm]

Hi Stian,

On Tue, Sep 22, 2026 at 4:38 PM Stian Halseth <stian@xxxxxx> wrote:
>
> I am adding HAVE_PERF_REGS and HAVE_PERF_USER_STACK_DUMP to sparc64, so
> that perf record --call-graph dwarf and elfutils' eu-stackprof work
> there. The sparc side (patch 2) is straightforward and follows parisc.
> One thing does not fit in arch code, and I would like to get the shape
> of that agreed before sending the rest.
>
> The user stack dump copies the stack as it is in memory and assumes the
> call chain is there. On sparc it may not be: the sampled register
> window's %l/%i registers, which hold the frame pointer and return
> address the unwinder starts from (the CFI after `save` defines the CFA
> in terms of %i6), stay in the register file until a window spills. The
> kernel already deals with this wherever it exposes user stack memory:
> perf_callchain_user() on sparc calls flushw_user() before walking the
> chain, and ptrace does the same. The stack dump has no arch entry
> point where that could happen.
>
> I looked for a sparc-only way and did not find a correct one:
>
> - flushing in the sparc PMU interrupt handler misses software events
>   (cpu-clock, tracepoints), which reach perf_event_overflow() without
>   passing through it;
> - perf_user_stack_pointer() is private to kernel/events/internal.h, so
>   the arch cannot override it;
> - perf_reg_abi() is called at the right time but is a query, and a
>   flush as a side effect of it would be wrong.
>
> So patch 1 adds a no-op hook in the style of perf_arch_misc_flags():
> perf_arch_prepare_ustack(), called from perf_prepare_sample() when
> PERF_SAMPLE_STACK_USER is requested and user regs exist. Patch 2 is the
> sparc64 implementation and its user. Happy to take a different name or
> placement.
>
> Tested on an UltraSPARC T4-1 on 7.3-rc4 with a perf tool taught the
> sparc registers (that patch, and the matching elfutils backend, follow
> once the hook is settled): register values check out against known
> contents, and --call-graph dwarf unwinds correctly for both cycles and
> cpu-clock. perf stat/record/record -g are unchanged.
>
> Link: https://github.com/sparclinux/issues/issues/99
>
> Stian Halseth (2):
>   perf/core: Let an arch prepare the user stack before it is dumped
>   sparc64: Support PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER
>
>  arch/sparc/Kconfig                      |  2 +
>  arch/sparc/include/asm/perf_event.h     |  3 ++
>  arch/sparc/include/uapi/asm/perf_regs.h | 33 +++++++++++++
>  arch/sparc/kernel/Makefile              |  2 +-
>  arch/sparc/kernel/perf_regs.c           | 65 +++++++++++++++++++++++++
>  include/linux/perf_event.h              |  7 +++
>  kernel/events/core.c                    |  2 +
>  7 files changed, 113 insertions(+), 1 deletion(-)
>  create mode 100644 arch/sparc/include/uapi/asm/perf_regs.h
>  create mode 100644 arch/sparc/kernel/perf_regs.c
>
> --
> 2.55.0
>


Very nice series, thanks for working on this!

I built and booted the series on a sparc64 box and haven't
noticed any regressions so far.

I also smoke-tested the new interfaces from 64-bit userspace with a
small standalone C program using perf_event_open() and software
cpu-clock events. The register-only, stack-only, and combined
register/stack tests all passed. The test does not use tools/perf or
request PERF_SAMPLE_CALLCHAIN. I haven't tested end-to-end DWARF
unwinding yet.

I see that you plan to post the userspace changes once the hook is
settled. Could you include the tools/perf support in the next revision,
or post it as a follow-up or linked companion series? Having that
available, along with a link to the matching elfutils changes, would
make testing easier and let us exercise the intended DWARF unwinding
use case directly.

Also, could you update the sparc entries from TODO to ok in:

  Documentation/features/perf/perf-regs/arch-support.txt
  Documentation/features/perf/perf-stackdump/arch-support.txt

Those updates would fit naturally in patch 2 alongside the
HAVE_PERF_REGS and HAVE_PERF_USER_STACK_DUMP selections.

Thanks,
Magnus