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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.