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: 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.
[2 lines not shown]
t_signal_and_sp: Test makecontext with uc_link too.
This exercises the resumecontext path, which currently leaves the
stack pointer misaligned on mipsn64 (note: not mips64, which is
64-bit mips with n32 ABI).
Also add some assertions about the stack pointer lying within the
expected stack range and mark riscv inexplicably broken for the
pthread_create sp. And mark the hppa context/thread tests broken --
not yet sure what's wrong with them.
PR kern/59327: user stack pointer is not aligned properly
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: 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 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 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: 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: 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
h_execregs: Properly request to statically link this.
Adding -static to LDFLAGS doesn't work because we end up passing
various other flags that cause it to come out as a dynamic executable
anyway, which would crash on SIGSEGV early at startup -- except that
the entry point exits before calling the normal start routine, so by
accident it works.
PR kern/59084: exec/spawn leaks register content
viaide(4): check if chip enable register returns 0 before emulating enable
bits.
At least some VT6410 controllers have register exposed. In fact, some
motherboards allow to control IDE channels (enable/disable them).
viaide(4): Improve VT8251 integrated SATA controller support in IDE/RAID modes.
Use via_chip_map() to attach this controller in IDE and RAID modes, similarly
to VX800. This allows drives to be identified and attached successfully on all
four ports (two channels with master/slave ports).
Switch channel setup to sata_setup_channel(), replacing via_setup_channel().
This avoids writes to the 0x50 register, which is only relevant for IDE
controllers. Writes to SATA controller registers caused drives on the IDE
controller (0x0571) to fail to attach. Apply this fix also to VX900 and VT8261.
Rename VT8237R_SATA to VT8251_SATA (0x3349 is not used for VT8237R, AFAIK).
This PCI ID is used in RAID mode on newer (CE) chipset revision and in all
modes (IDE/RAID/AHCI) on older revision.
Add the 0x5287 PCI ID, used in IDE mode on newer (CE) chipset revision.
Rename VT8251_SATA to VT8251_AHCI (0x6287 is used only in AHCI mode).
Add VT8251_AHCI to the ahcisata(4) quirk list, same as VT8251_SATA.
For more details, see the tech-kern thread:
[7 lines not shown]
Pull up following revision(s) (requested by tls in ticket #1941):
external/ibm-public/postfix/sbin/postconf/Makefile: revision 1.10
Fix toolchain/59302 which, as it turns out, is caused not by building
on Linux, but by building in any directory whose full path to the root
contains "tls" or "global".
Pull up following revision(s) (requested by tls in ticket #1097):
external/ibm-public/postfix/sbin/postconf/Makefile: revision 1.10
Fix toolchain/59302 which, as it turns out, is caused not by building
on Linux, but by building in any directory whose full path to the root
contains "tls" or "global".
