Re: [PATCH] alpha: Add PTRACE_GETREGSET/PTRACE_SETREGSET support
Magnus Lindholm <[email protected]>
| Newsgroups | org.kernel.vger.linux-alpha,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CA+=Fv5TYDKQRo8mBd0XhFE2PwHqMHFG1qD=RxSLYZ7qUEbs4Aw@mail.gmail.com> |
On Fri, Apr 3, 2026 at 5:07 PM Matt Turner <[email protected]> wrote: > > Enable HAVE_ARCH_TRACEHOOK and implement task_user_regset_view() to > provide regset-based register access on Alpha. This adds support for > PTRACE_GETREGSET and PTRACE_SETREGSET, which are handled by the > generic ptrace_request() path. > > Two regsets are defined: > - REGSET_GENERAL (NT_PRSTATUS): 33 registers (32 GPRs + unique), > matching the existing elf_gregset_t layout used by dump_elf_thread() > - REGSET_FPU (NT_PRFPREG): 32 floating-point registers from > thread_info->fp[] > > Also implement the full set of syscall accessor functions in > asm/syscall.h and user_stack_pointer() in asm/ptrace.h, which are > required by the generic PTRACE_GET_SYSCALL_INFO code that > HAVE_ARCH_TRACEHOOK enables. > > Assisted-by: Claude:claude-opus-4-6 > Signed-off-by: Matt Turner <[email protected]> > --- > This is an implementation of PTRACE_{G,S}ETREGSET using the standard > infrastructure. > > arch/alpha/Kconfig | 1 + > arch/alpha/include/asm/ptrace.h | 12 +++ > arch/alpha/include/asm/syscall.h | 67 ++++++++++++++- > arch/alpha/kernel/ptrace.c | 137 +++++++++++++++++++++++++++++++ > 4 files changed, 215 insertions(+), 2 deletions(-) > Thanks for working on this, this is a really useful step towards getting Alpha onto the generic ptrace/regset infrastructure. I’ve been comparing this with parallel patch series: - alpha: enable regset-based ptrace and core dumps: https://git.kernel.org/pub/scm/linux/kernel/git/lindholm/alpha.git/log/?h=entry - SECCOMPv3: https://lore.kernel.org/linux-alpha/[email protected]/ Especially what I’ve been referring to as the SECCOMPv3 patch, and I think the cleanest way forward upstream would be to stage this a bit differently. In particular, I would suggest: 1. First let the SECCOMPv3 patch land upstream. That patch establishes the new syscall register model (r1 = current nr, r2 = original nr, r0 = return value, r19 = error flag) and provides the syscall accessors expected by generic code. 2. Then rework this patch on top of that new baseline. As it stands, this patch assumes the old Alpha syscall conventions (e.g. syscall nr in r0, no rollback state, etc.), which will conflict semantically once the SECCOMPv3 changes are merged. In particular, the asm/syscall.h additions here should be aligned with (or dropped in favour of) the SECCOMPv3 definitions, so that: - syscall_get_nr() uses r1 - syscall_set_nr() updates r1 - syscall_rollback() restores r1 from r2 - return/error handling matches the r0/r19 contract My suggestion would be to avoid duplicating that logic here entirely and instead rely on the SECCOMPv3 version, only adding anything that is still missing for PTRACE_GET_SYSCALL_INFO. 3. Keep this patch focused on ptrace/regset enablement. The regset pieces (task_user_regset_view(), GPR/FPR sets, etc.) look like a good fit for the generic ptrace_request() path once HAVE_ARCH_TRACEHOOK is enabled. For now, we would leave out the ELF core dump changes from the other series and handle those as a follow-up once the ptrace side is settled. 4. One open point is how we want to handle the user stack pointer (USP). This patch derives USP from thread_info/PCB, while the other series snapshots it into pt_regs. It would be good to settle on one model before merging regset support, as it affects user_stack_pointer() and the GPR regset layout. Either approach is workable as long as it is consistent. I think structuring it this way gives a clear upstream story: - SECCOMPv3: establish new syscall state - this patch (reworked): enable regset-based ptrace - later: possibly switch ELF core dumps to regsets Any thought on this approach? Magnus Lindholm