Remove kernel/arch/{amd64,i386,x86} tests

These files were merged with kernel/t_ptrace_wait*

This removes MD test files.

Sponsored by <The NetBSD Foundation>

Add kernel/arch/x86 ATF tests for CPU Debug Registers for amd64 and i386

This moves kernel/arch/amd64 tests, the ones to be shared between amd64 and
i386, into kernel/arch/x86. This covers all Debug Register tests.

kernel/arch/amd64 is reduced to regs1
kernel/arch/i386 is reduced to regs1

kernel/arch/x86 tests:
- dbregs_print
- dbregs_preserve_dr0
- dbregs_preserve_dr1
- dbregs_preserve_dr2
- dbregs_preserve_dr3
- dbregs_preserve_dr0_yield
- dbregs_preserve_dr1_yield
- dbregs_preserve_dr2_yield
- dbregs_preserve_dr3_yield
- dbregs_preserve_dr0_continued
- dbregs_preserve_dr1_continued
- dbregs_preserve_dr2_continued
- dbregs_preserve_dr3_continued
- dbregs_dr0_trap_variable_writeonly_byte
- dbregs_dr1_trap_variable_writeonly_byte
- dbregs_dr2_trap_variable_writeonly_byte
- dbregs_dr3_trap_variable_writeonly_byte
- dbregs_dr0_trap_variable_writeonly_2bytes
- dbregs_dr1_trap_variable_writeonly_2bytes
- dbregs_dr2_trap_variable_writeonly_2bytes
- dbregs_dr3_trap_variable_writeonly_2bytes
- dbregs_dr0_trap_variable_writeonly_4bytes
- dbregs_dr1_trap_variable_writeonly_4bytes
- dbregs_dr2_trap_variable_writeonly_4bytes
- dbregs_dr3_trap_variable_writeonly_4bytes
- dbregs_dr0_trap_variable_readwrite_write_byte
- dbregs_dr1_trap_variable_readwrite_write_byte
- dbregs_dr2_trap_variable_readwrite_write_byte
- dbregs_dr3_trap_variable_readwrite_write_byte
- dbregs_dr0_trap_variable_readwrite_write_2bytes
- dbregs_dr1_trap_variable_readwrite_write_2bytes
- dbregs_dr2_trap_variable_readwrite_write_2bytes
- dbregs_dr3_trap_variable_readwrite_write_2bytes
- dbregs_dr0_trap_variable_readwrite_write_4bytes
- dbregs_dr1_trap_variable_readwrite_write_4bytes
- dbregs_dr2_trap_variable_readwrite_write_4bytes
- dbregs_dr3_trap_variable_readwrite_write_4bytes
- dbregs_dr0_trap_variable_readwrite_read_byte
- dbregs_dr1_trap_variable_readwrite_read_byte
- dbregs_dr2_trap_variable_readwrite_read_byte
- dbregs_dr3_trap_variable_readwrite_read_byte
- dbregs_dr0_trap_variable_readwrite_read_2bytes
- dbregs_dr1_trap_variable_readwrite_read_2bytes
- dbregs_dr2_trap_variable_readwrite_read_2bytes
- dbregs_dr3_trap_variable_readwrite_read_2bytes
- dbregs_dr0_trap_variable_readwrite_read_4bytes
- dbregs_dr1_trap_variable_readwrite_read_4bytes
- dbregs_dr2_trap_variable_readwrite_read_4bytes
- dbregs_dr3_trap_variable_readwrite_read_4bytes
- dbregs_dr0_trap_code
- dbregs_dr1_trap_code
- dbregs_dr2_trap_code
- dbregs_dr3_trap_code
- dbregs_dr0_dont_inherit_lwp
- dbregs_dr1_dont_inherit_lwp
- dbregs_dr2_dont_inherit_lwp
- dbregs_dr3_dont_inherit_lwp
- dbregs_dr6_dont_inherit_lwp
- dbregs_dr7_dont_inherit_lwp
- dbregs_dr0_dont_inherit_execve
- dbregs_dr1_dont_inherit_execve
- dbregs_dr2_dont_inherit_execve
- dbregs_dr3_dont_inherit_execve
- dbregs_dr6_dont_inherit_execve
- dbregs_dr7_dont_inherit_execve

Sponsored by <The NetBSD Foundation>

branches: 1.2.2; 1.2.4;
Add regs1 in arch/i386/t_ptrace_wait*

regs1:
Call PT_GETREGS and iterate over General Purpose registers

Sponsored by <The NetBSD Foundation>

Refactor location of amd64-specific ATF tests to new dir kernel/arch/amd64

Rename
- tests/kernel/t_ptrace_amd64_wait.c
to
- tests/kernel/arch/amd64/t_ptrace_wait.c
and adapt appropriate files accordingly.

New directory will be used for more amd64-specific tests, verifying the
MD parts of the kernel.

Remove old entries from distrib/sets/lists as they were added a while ago.

Sponsored by <The NetBSD Foundation>

Remove kernel/arch/{amd64,i386,x86} tests

These files were merged with kernel/t_ptrace_wait*

This removes MD test files.

Sponsored by <The NetBSD Foundation>

branches: 1.1.2; 1.1.4;
Refactor location of amd64-specific ATF tests to new dir kernel/arch/amd64

Rename
- tests/kernel/t_ptrace_amd64_wait.c
to
- tests/kernel/arch/amd64/t_ptrace_wait.c
and adapt appropriate files accordingly.

New directory will be used for more amd64-specific tests, verifying the
MD parts of the kernel.

Remove old entries from distrib/sets/lists as they were added a while ago.

Sponsored by <The NetBSD Foundation>

branches: 1.2.4;
try to fix the clang build: :pg_hi21: is a gas extension.

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

branches: 1.1.4;
Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

branches: 1.1.4;
Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

branches: 1.3.4;
try to fix the clang build: :pg_hi21: is a gas extension.

t_signal_and_sp: Check sp on elf constructor/destructor entry too.

XXX Should maybe test both .ctors/.dtors and .init/fini_array, but
for now I'm limiting this to whatever gcc uses by default for each
architecture.

PR kern/59327: user stack pointer is not aligned properly

Test stack pointer alignment in various scenarios.

1. elf entry point
2. main function
3. signal handler

Extend the test to amd64 while here -- fortunately both aarch64 and
amd64 pass, but others, such as mips, will fail:

PR kern/59327: user stack pointer is not aligned properly

This extends the test that was previously written for:

PR kern/58149: aarch64: Cannot return from a signal handler if SP was
misaligned when the signal arrived

With any luck, this will help us to systematically eradicate misaligned
stack pointers as hypothesized to be the reason for:

PR port-mips/59236: Multiple segfaults in erlite3 boot

branches: 1.2.4;
t_execregs: On aarch64, make sure to align stack to 16 bytes.

Should avoid SIGBUS with strict alignment (SCTLR_EL0.A bit).

PR kern/59084: exec/spawn leaks register content

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

branches: 1.2.4;
try to fix the clang build: :pg_hi21: is a gas extension.

Test stack pointer alignment in various scenarios.

1. elf entry point
2. main function
3. signal handler

Extend the test to amd64 while here -- fortunately both aarch64 and
amd64 pass, but others, such as mips, will fail:

PR kern/59327: user stack pointer is not aligned properly

This extends the test that was previously written for:

PR kern/58149: aarch64: Cannot return from a signal handler if SP was
misaligned when the signal arrived

With any luck, this will help us to systematically eradicate misaligned
stack pointers as hypothesized to be the reason for:

PR port-mips/59236: Multiple segfaults in erlite3 boot

Test stack pointer alignment in various scenarios.

1. elf entry point
2. main function
3. signal handler

Extend the test to amd64 while here -- fortunately both aarch64 and
amd64 pass, but others, such as mips, will fail:

PR kern/59327: user stack pointer is not aligned properly

This extends the test that was previously written for:

PR kern/58149: aarch64: Cannot return from a signal handler if SP was
misaligned when the signal arrived

With any luck, this will help us to systematically eradicate misaligned
stack pointers as hypothesized to be the reason for:

PR port-mips/59236: Multiple segfaults in erlite3 boot

branches: 1.1.2;
Add a test for kern/58149

aarch64: Cannot return from a signal handler if SP was misaligned when the signal arrived

branches: 1.1.4;
t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Fix main function on alpha so it returns zero.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Add alpha support.

Turns out alpha too gets confused by by misaligned sigaltstack, and
by misaligned sp in the interrupted code, when a signal is delivered.

PR kern/59327: user stack pointer is not aligned properly

PR kern/58149: Cannot return from a signal handler if SP was
misaligned when the signal arrived

t_signal_and_sp: Add alpha support.

Turns out alpha too gets confused by by misaligned sigaltstack, and
by misaligned sp in the interrupted code, when a signal is delivered.

PR kern/59327: user stack pointer is not aligned properly

PR kern/58149: Cannot return from a signal handler if SP was
misaligned when the signal arrived

t_signal_and_sp: Add alpha support.

Turns out alpha too gets confused by by misaligned sigaltstack, and
by misaligned sp in the interrupted code, when a signal is delivered.

PR kern/59327: user stack pointer is not aligned properly

PR kern/58149: Cannot return from a signal handler if SP was
misaligned when the signal arrived

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

arm: asm.h - change GOT_INIT to take the normal asm label

Don't pass the label to use for the "current address" as the macro
parameter. It obscures its purpose and makes the use of local labels
extremely unobvious, so you are forced to invent a name that is mostly
useless otherwise:

GOT_INIT(r3, .Lgot.execsp_start, .Lpc.execsp_start)
GOT_INITSYM(.Lgot.execsp_start, .Lpc.execsp_start)
vs.
0: GOT_INIT(r3, .Lgot.execsp_start)
GOT_INITSYM(.Lgot.execsp_start, 0b)

Same object code is generated.

t_signal_and_sp: Draft add arm support.

Compile-tested only, let's see how this goes.

PR kern/59327: user stack pointer is not aligned properly

arm: asm.h - change GOT_INIT to take the normal asm label

Don't pass the label to use for the "current address" as the macro
parameter. It obscures its purpose and makes the use of local labels
extremely unobvious, so you are forced to invent a name that is mostly
useless otherwise:

GOT_INIT(r3, .Lgot.execsp_start, .Lpc.execsp_start)
GOT_INITSYM(.Lgot.execsp_start, .Lpc.execsp_start)
vs.
0: GOT_INIT(r3, .Lgot.execsp_start)
GOT_INITSYM(.Lgot.execsp_start, 0b)

Same object code is generated.

Make main() actually return zero. From Riastradh.
PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp arm/execsp.S: Try using registers that aren't in use.

The first draft of this was instead using all the registers that
_are_ in use on entry to the elf entry point, which understandably
confused __start when we jumped to it after trashing all its inputs.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Draft add arm support.

Compile-tested only, let's see how this goes.

PR kern/59327: user stack pointer is not aligned properly

arm: asm.h - change GOT_INIT to take the normal asm label

Don't pass the label to use for the "current address" as the macro
parameter. It obscures its purpose and makes the use of local labels
extremely unobvious, so you are forced to invent a name that is mostly
useless otherwise:

GOT_INIT(r3, .Lgot.execsp_start, .Lpc.execsp_start)
GOT_INITSYM(.Lgot.execsp_start, .Lpc.execsp_start)
vs.
0: GOT_INIT(r3, .Lgot.execsp_start)
GOT_INITSYM(.Lgot.execsp_start, 0b)

Same object code is generated.

t_signal_and_sp arm/signalsphandler.S: Fix pasto.

Copied & pasted this from contextspfunc.S and forgot to change one
reference to contextsp to signalsp instead, oops.

Should resolve:

*** Check failed: /work/src/tests/kernel/t_signal_and_sp.c:440: signalsp != NULL not met

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Draft add arm support.

Compile-tested only, let's see how this goes.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Draft add arm support.

Compile-tested only, let's see how this goes.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Draft add arm support.

Compile-tested only, let's see how this goes.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Fix threadsp test to actually test the thread sp.

Copypasta error had it testing alignment of signalsp instead, and
since it was always null, that always passed. Mark it xfail on mips
now as originally expected.

While here, deal with some other issues:

- Test was failing on riscv for me because I haven't updated this
`current' VM in a while so it didn't have the fix for 57721
(pthread_attr_setstack incorrectly adjusts address as if for guard
page). Don't mark it xfail.

- Fix amd64 threadspfunc.S to adjust rsp like in all the other amd64
stubs so it's congruent to 0 mod 16, not congruent to 8 mod 16.

- Fix hppa contextspfunc.S to use separate registers for separate
purposes at the same time, instead of expecting addil to preserve
%r1 AND yield a result we use later in %r1.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

t_execregs: Test some more registers on hppa.

Looks like we're missing zeroing of floating-point registers too, as
well as the carry/borrow and divide step correction bits in the
semi-secret PSW register.

Unfortunately, while investigating this, I discovered that qemu's
hppa implementation doesn't implement fpu traps even if the fpu is
disabled (relevant bits of CR 10 `CCR', Coprocessor Control Register,
are cleared), which breaks fpu switching on NetBSD. So I can't test
properly this myself. We should maybe just change NetBSD from lazy
fpu switching to eager fpu switching anyway to thwart Spectre-class
attacks if there's any hppa hardware out there that does speculative
execution.

PR kern/59084: exec/spawn leaks register content

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

t_execregs: Test some more registers on hppa.

Looks like we're missing zeroing of floating-point registers too, as
well as the carry/borrow and divide step correction bits in the
semi-secret PSW register.

Unfortunately, while investigating this, I discovered that qemu's
hppa implementation doesn't implement fpu traps even if the fpu is
disabled (relevant bits of CR 10 `CCR', Coprocessor Control Register,
are cleared), which breaks fpu switching on NetBSD. So I can't test
properly this myself. We should maybe just change NetBSD from lazy
fpu switching to eager fpu switching anyway to thwart Spectre-class
attacks if there's any hppa hardware out there that does speculative
execution.

PR kern/59084: exec/spawn leaks register content

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

t_signal_and_sp: Add hppa support.

Fortunately, hppa -- which uses monster 64-byte(!) stack alignment --
looks good already.

PR kern/59327: user stack pointer is not aligned properly

t_execregs: Test some more registers on hppa.

Looks like we're missing zeroing of floating-point registers too, as
well as the carry/borrow and divide step correction bits in the
semi-secret PSW register.

Unfortunately, while investigating this, I discovered that qemu's
hppa implementation doesn't implement fpu traps even if the fpu is
disabled (relevant bits of CR 10 `CCR', Coprocessor Control Register,
are cleared), which breaks fpu switching on NetBSD. So I can't test
properly this myself. We should maybe just change NetBSD from lazy
fpu switching to eager fpu switching anyway to thwart Spectre-class
attacks if there's any hppa hardware out there that does speculative
execution.

PR kern/59084: exec/spawn leaks register content

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

t_signal_and_sp: Add hppa support.

Fortunately, hppa -- which uses monster 64-byte(!) stack alignment --
looks good already.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Add hppa support.

Fortunately, hppa -- which uses monster 64-byte(!) stack alignment --
looks good already.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

Remove kernel/arch/{amd64,i386,x86} tests

These files were merged with kernel/t_ptrace_wait*

This removes MD test files.

Sponsored by <The NetBSD Foundation>

branches: 1.1.2; 1.1.4;
Add regs1 in arch/i386/t_ptrace_wait*

regs1:
Call PT_GETREGS and iterate over General Purpose registers

Sponsored by <The NetBSD Foundation>

Remove kernel/arch/{amd64,i386,x86} tests

These files were merged with kernel/t_ptrace_wait*

This removes MD test files.

Sponsored by <The NetBSD Foundation>

branches: 1.1.2; 1.1.4;
Add regs1 in arch/i386/t_ptrace_wait*

regs1:
Call PT_GETREGS and iterate over General Purpose registers

Sponsored by <The NetBSD Foundation>

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

t_signal_and_sp: Add i386 support.

i386 too is confused by misaligned sigaltstack or esp on interrupt.

PR kern/59327: user stack pointer is not aligned properly

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

t_signal_and_sp: Add i386 support.

i386 too is confused by misaligned sigaltstack or esp on interrupt.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Add i386 support.

i386 too is confused by misaligned sigaltstack or esp on interrupt.

PR kern/59327: user stack pointer is not aligned properly

Remove kernel/arch/{amd64,i386,x86} tests

These files were merged with kernel/t_ptrace_wait*

This removes MD test files.

Sponsored by <The NetBSD Foundation>

branches: 1.2.2;
Don't play with "../.." in includes for h_macros.h; deal with it centrally.
Minor fixes.

branches: 1.1.2;
Add regs1 in arch/i386/t_ptrace_wait*

regs1:
Call PT_GETREGS and iterate over General Purpose registers

Sponsored by <The NetBSD Foundation>

Remove kernel/arch/{amd64,i386,x86} tests

These files were merged with kernel/t_ptrace_wait*

This removes MD test files.

Sponsored by <The NetBSD Foundation>

branches: 1.1.2; 1.1.4;
Add regs1 in arch/i386/t_ptrace_wait*

regs1:
Call PT_GETREGS and iterate over General Purpose registers

Sponsored by <The NetBSD Foundation>

Remove kernel/arch/{amd64,i386,x86} tests

These files were merged with kernel/t_ptrace_wait*

This removes MD test files.

Sponsored by <The NetBSD Foundation>

branches: 1.1.2; 1.1.4;
Add regs1 in arch/i386/t_ptrace_wait*

regs1:
Call PT_GETREGS and iterate over General Purpose registers

Sponsored by <The NetBSD Foundation>

Remove kernel/arch/{amd64,i386,x86} tests

These files were merged with kernel/t_ptrace_wait*

This removes MD test files.

Sponsored by <The NetBSD Foundation>

branches: 1.1.2; 1.1.4;
Add regs1 in arch/i386/t_ptrace_wait*

regs1:
Call PT_GETREGS and iterate over General Purpose registers

Sponsored by <The NetBSD Foundation>

Remove kernel/arch/{amd64,i386,x86} tests

These files were merged with kernel/t_ptrace_wait*

This removes MD test files.

Sponsored by <The NetBSD Foundation>

branches: 1.1.2; 1.1.4;
Add regs1 in arch/i386/t_ptrace_wait*

regs1:
Call PT_GETREGS and iterate over General Purpose registers

Sponsored by <The NetBSD Foundation>

Remove kernel/arch/{amd64,i386,x86} tests

These files were merged with kernel/t_ptrace_wait*

This removes MD test files.

Sponsored by <The NetBSD Foundation>

branches: 1.1.2; 1.1.4;
Add regs1 in arch/i386/t_ptrace_wait*

regs1:
Call PT_GETREGS and iterate over General Purpose registers

Sponsored by <The NetBSD Foundation>

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Try to fix mips o32 tests.

Evidently, for o32, PIC_PROLOGUE (which expands to .cpload) must be
the very first instruction of the function, or else it will get the
$gp calculation wrong.

Since it seems that the mips PIC_PROLOGUE does not, after all, mess
with the stack, let's just dispense with the temporary copy of sp in
t0 which I had added in paranoia over what magic might happen inside
PIC_PROLOGUE. (Such paranoia is not entirely unjustified -- for
example, the sh3 PIC_PROLOGUE _does_ push data on the stack, though
this can be bypassed with PIC_PROLOGUE_NOSAVE.)

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Try to fix mips o32 tests.

Evidently, for o32, PIC_PROLOGUE (which expands to .cpload) must be
the very first instruction of the function, or else it will get the
$gp calculation wrong.

Since it seems that the mips PIC_PROLOGUE does not, after all, mess
with the stack, let's just dispense with the temporary copy of sp in
t0 which I had added in paranoia over what magic might happen inside
PIC_PROLOGUE. (Such paranoia is not entirely unjustified -- for
example, the sh3 PIC_PROLOGUE _does_ push data on the stack, though
this can be bypassed with PIC_PROLOGUE_NOSAVE.)

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Add mips support.

PR kern/59327: user stack pointer is not aligned properly

PR kern/58149: Cannot return from a signal handler if SP was
misaligned when the signal arrived

Stack pointer misaligment in some cases hypothesized to be a possible
cause of:

PR port-evbmips/59236: Multiple segfaults in erlite3 boot

t_signal_and_sp: Try to fix mips o32 tests.

Evidently, for o32, PIC_PROLOGUE (which expands to .cpload) must be
the very first instruction of the function, or else it will get the
$gp calculation wrong.

Since it seems that the mips PIC_PROLOGUE does not, after all, mess
with the stack, let's just dispense with the temporary copy of sp in
t0 which I had added in paranoia over what magic might happen inside
PIC_PROLOGUE. (Such paranoia is not entirely unjustified -- for
example, the sh3 PIC_PROLOGUE _does_ push data on the stack, though
this can be bypassed with PIC_PROLOGUE_NOSAVE.)

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Add mips support.

PR kern/59327: user stack pointer is not aligned properly

PR kern/58149: Cannot return from a signal handler if SP was
misaligned when the signal arrived

Stack pointer misaligment in some cases hypothesized to be a possible
cause of:

PR port-evbmips/59236: Multiple segfaults in erlite3 boot

t_signal_and_sp: mips: Fix {MISALIGN,FIX}_SP() for !o32

Use `daddiu` instead of `addiu` as done in <mips/asm.h>.

Otherwise, +/-1 is added to lower-32-bits of sp, and then
results are sign-extended to whole-64-bits register (oops!!).

t_signal_and_sp: Add mips support.

PR kern/59327: user stack pointer is not aligned properly

PR kern/58149: Cannot return from a signal handler if SP was
misaligned when the signal arrived

Stack pointer misaligment in some cases hypothesized to be a possible
cause of:

PR port-evbmips/59236: Multiple segfaults in erlite3 boot

t_signal_and_sp: Fix threadspfunc on mips.

1. Writing branch delay slots requires `.set noreorder'. Got used to
reading and writing RISCy code with branch delay slots ages ago,
still haven't gotten used to having to tell the assembler `no, I
really want you to assemble the instructions I wrote, as I wrote
them, and not some other instructions in some other order'.

2. Return value is v0 on mips, not a0 like modern mips^W^Wriscv.

With this, the threadsp test passes on mips.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

t_signal_sp: Add riscv support.

riscv64 looks good, haven't tested riscv32.

PR kern/59327: user stack pointer is not aligned properly

t_signal_sp: Add riscv support.

riscv64 looks good, haven't tested riscv32.

PR kern/59327: user stack pointer is not aligned properly

t_signal_sp: Add riscv support.

riscv64 looks good, haven't tested riscv32.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: add sh3 support

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: add sh3 support

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Fix RCSID in sh3/execsp.S.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: add sh3 support

PR kern/59327: user stack pointer is not aligned properly

t_execregs: implement sh3 h_execregs helper

Just dumps mcontext __gregset_t for now.
Not yet hooked into the build.

t_signal_and_sp: sh3 - mark expected failures

misaligned_sp_and_signal and signalsp_sigaltstack currently fail on
sh3 b/c the stack is not force-aligned for signal handlers. Make
signalsphandler more robust by not touching the stack - we can save
r12 (GOT) in a register.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: add sh3 support

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: add sh3 support

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: add sh3 support

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Add sparc support.

Seems fine! Would be nice if we had a well-known macro to abstract
PIC vs non-PIC `sethi/ori/(ld)' like I invented here, to reduce
needless #ifdef __PIC__ conditionals.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Add sparc support.

Seems fine! Would be nice if we had a well-known macro to abstract
PIC vs non-PIC `sethi/ori/(ld)' like I invented here, to reduce
needless #ifdef __PIC__ conditionals.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Add sparc support.

Seems fine! Would be nice if we had a well-known macro to abstract
PIC vs non-PIC `sethi/ori/(ld)' like I invented here, to reduce
needless #ifdef __PIC__ conditionals.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

t_signal_and_sp: Check sp on elf constructor/destructor entry too.

XXX Should maybe test both .ctors/.dtors and .init/fini_array, but
for now I'm limiting this to whatever gcc uses by default for each
architecture.

PR kern/59327: user stack pointer is not aligned properly

Test stack pointer alignment in various scenarios.

1. elf entry point
2. main function
3. signal handler

Extend the test to amd64 while here -- fortunately both aarch64 and
amd64 pass, but others, such as mips, will fail:

PR kern/59327: user stack pointer is not aligned properly

This extends the test that was previously written for:

PR kern/58149: aarch64: Cannot return from a signal handler if SP was
misaligned when the signal arrived

With any luck, this will help us to systematically eradicate misaligned
stack pointers as hypothesized to be the reason for:

PR port-mips/59236: Multiple segfaults in erlite3 boot

Test whether exec/spawn will zero registers.

Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).

VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.

PR kern/59084: exec/spawn leaks register content

Test stack pointer alignment in various scenarios.

1. elf entry point
2. main function
3. signal handler

Extend the test to amd64 while here -- fortunately both aarch64 and
amd64 pass, but others, such as mips, will fail:

PR kern/59327: user stack pointer is not aligned properly

This extends the test that was previously written for:

PR kern/58149: aarch64: Cannot return from a signal handler if SP was
misaligned when the signal arrived

With any luck, this will help us to systematically eradicate misaligned
stack pointers as hypothesized to be the reason for:

PR port-mips/59236: Multiple segfaults in erlite3 boot

Test stack pointer alignment in various scenarios.

1. elf entry point
2. main function
3. signal handler

Extend the test to amd64 while here -- fortunately both aarch64 and
amd64 pass, but others, such as mips, will fail:

PR kern/59327: user stack pointer is not aligned properly

This extends the test that was previously written for:

PR kern/58149: aarch64: Cannot return from a signal handler if SP was
misaligned when the signal arrived

With any luck, this will help us to systematically eradicate misaligned
stack pointers as hypothesized to be the reason for:

PR port-mips/59236: Multiple segfaults in erlite3 boot

t_signal_and_sp: Fix threadsp test to actually test the thread sp.

Copypasta error had it testing alignment of signalsp instead, and
since it was always null, that always passed. Mark it xfail on mips
now as originally expected.

While here, deal with some other issues:

- Test was failing on riscv for me because I haven't updated this
`current' VM in a while so it didn't have the fix for 57721
(pthread_attr_setstack incorrectly adjusts address as if for guard
page). Don't mark it xfail.

- Fix amd64 threadspfunc.S to adjust rsp like in all the other amd64
stubs so it's congruent to 0 mod 16, not congruent to 8 mod 16.

- Fix hppa contextspfunc.S to use separate registers for separate
purposes at the same time, instead of expecting addil to preserve
%r1 AND yield a result we use later in %r1.

PR kern/59327: user stack pointer is not aligned properly

t_signal_and_sp: Test makecontext and pthread_create stack alignment.

PR kern/59327: user stack pointer is not aligned properly