On Sun, Sep 6, 2026 at 4:44 PM Magnus Lindholm <[email protected]> wrote: > > Hi Matt, > > On Sat, Sep 5, 2026 at 9:30 PM Matt Turner <[email protected]> wrote: > > > > Implement the perf register sampling interface for Alpha. This enables > > perf to capture register state and user stack dumps with samples, > > supporting --call-graph dwarf. > > > > The perf_regs enum exposes the registers available in pt_regs: r0-r8, > > r16-r28, gp, pc, and ps. Registers r9-r15 are callee-saved and live > > in switch_stack, not pt_regs, so they are not included. > > > > A switch statement maps perf register indices to pt_regs fields since > > Alpha's pt_regs layout is non-contiguous (unlike architectures where > > direct array indexing works). > > > > Assisted-by: Claude:claude-opus-4-6 > > Signed-off-by: Matt Turner <[email protected]> > > I think this patch still needs kernel-side work in addition to the > matching tools/perf support. > > HAVE_PERF_USER_STACK_DUMP makes the generic perf code obtain the user > stack pointer through user_stack_pointer(regs), which on Alpha returns > regs->usp. However, the interrupt SAVE_ALL path does not initialize > that field, and do_entInt() does not snapshot USP. A profiling > interrupt taken from user mode may therefore attempt to copy the stack > from a stale or uninitialized address. > > The proposed perf register ABI also does not include SP. A DWARF > unwinder needs both the sampled stack contents and the corresponding > stack pointer, so this cannot be completed solely by a later > tools/perf patch. > > Would it make sense to drop this patch from the current series and > submit the perf support separately, including USP capture on interrupt > entry, SP in the kernel perf register ABI, and the matching tools/perf > support? That would allow the rest of this series to proceed without > waiting for the perf interface to be completed.
Yes, let's drop this patch from the series.
