CVS commit: [netbsd-11] src/sys

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Sat Oct 24 10:14:08 UTC 2026

Modified Files:
        src/sys/arch/amd64/amd64 [netbsd-11]: process_machdep.c
        src/sys/arch/i386/i386 [netbsd-11]: process_machdep.c
        src/sys/arch/x86/include [netbsd-11]: dbregs.h
        src/sys/arch/x86/x86 [netbsd-11]: dbregs.c
        src/sys/compat/netbsd32 [netbsd-11]: netbsd32_ptrace.c
        src/sys/kern [netbsd-11]: sys_process_lwpstatus.c
        src/sys/sys [netbsd-11]: ptrace.h

Log Message:
Pull up following revision(s) (requested by riastradh in ticket #540):

        sys/kern/sys_process_lwpstatus.c: revision 1.6
        sys/kern/sys_process_lwpstatus.c: revision 1.7
        sys/kern/sys_process_lwpstatus.c: revision 1.8
        sys/arch/x86/include/dbregs.h: revision 1.9
        sys/kern/sys_process_lwpstatus.c: revision 1.9
        sys/sys/ptrace.h: revision 1.78
        sys/arch/x86/x86/dbregs.c: revision 1.16
        sys/kern/sys_process_lwpstatus.c: revision 1.10
        sys/arch/i386/i386/process_machdep.c: revision 1.98
        sys/compat/netbsd32/netbsd32_ptrace.c: revision 1.10
        sys/compat/netbsd32/netbsd32_ptrace.c: revision 1.11
        sys/arch/amd64/amd64/process_machdep.c: revision 1.51

ptrace/procfs: Take lwp lock around process_read/write_(fp)regs(32).

And verify that the lwp is in LSSTOP state before trying to read.

Otherwise, we might catch an lwp while it's still running on the CPU,
with all FPU state active, making the result unstable and tripping
assertions on some architectures.

PR port-amd64/60556: panic in process_read_fpregs_xmm

proc_regio: Clarify control flow and sprinkle comments.

Use `if (error) goto out' instead of `if (error == 0) error = ...' to
make the error case non-linear and indented, and the success case a
straight line of logic.

No functional change intended.

PR port-amd64/60556: panic in process_read_fpregs_xmm

x86: Pull dbregs buffer allocation out from under lwp_lock.

Sprinkle assertions and notes about locking rules while here.

PR kern/60595: System lockup using gdb(1) on kernel with DEBUG+LOCKDEBUG

This fixes a bug that was revealed by lifting up rock while fixing:
PR kern/60556: panic in process_read_fpregs_xmm

netbsd32_ptrace: Fix locking around ptrace register access.
PR kern/60658: netbsd32_process_read_dbregs() needs the same fix as
native amd64 process_read_dbregs()

ptrace(2): Tidy register access: no sketchy function pointer casts.

Followups for:
PR port-amd64/60556: panic in process_read_fpregs_xmm
PR kern/60595: System lockup using gdb(1) on kernel with
DEBUG+LOCKDEBUG
PR kern/60658: netbsd32_process_read_dbregs() needs the same fix as
native amd64 process_read_dbregs()

ptrace(2): Fix compat32 register set types in previous.

Not always `struct reg32' or `struct fpreg32', notably on arm32 --
make sure to say `process_reg32'/`process_fpreg32'/`process_dbreg32'.
(Here `compat32' means oabi?)

Followups for:
PR port-amd64/60556: panic in process_read_fpregs_xmm
PR kern/60595: System lockup using gdb(1) on kernel with
DEBUG+LOCKDEBUG
PR kern/60658: netbsd32_process_read_dbregs() needs the same fix as
native amd64 process_read_dbregs()

netbsd32_ptrace: Need to pre-allocate dbregs before read/write.

Followup for:
PR kern/60658: netbsd32_process_read_dbregs() needs the same fix as
native amd64 process_read_dbregs()


To generate a diff of this commit:
cvs rdiff -u -r1.50 -r1.50.4.1 src/sys/arch/amd64/amd64/process_machdep.c
cvs rdiff -u -r1.97 -r1.97.4.1 src/sys/arch/i386/i386/process_machdep.c
cvs rdiff -u -r1.8 -r1.8.38.1 src/sys/arch/x86/include/dbregs.h
cvs rdiff -u -r1.15 -r1.15.32.1 src/sys/arch/x86/x86/dbregs.c
cvs rdiff -u -r1.9 -r1.9.12.1 src/sys/compat/netbsd32/netbsd32_ptrace.c
cvs rdiff -u -r1.5 -r1.5.2.1 src/sys/kern/sys_process_lwpstatus.c
cvs rdiff -u -r1.77 -r1.77.2.1 src/sys/sys/ptrace.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.