unaligned data address causing the fault - this will always fail.
If anybody knows a portable way to get the data address involved in the
fault, please fix the test case as originally intended.
That one is tedious to test under x86: alignment exceptions are
not reported by this architecture unless you ask for them explicitely (by
setting the PSL_AC bit). The brokenness does not end there: %cr2 should
contain the address where the unaligned access occured, alas, it does not.
I am not aware of other architectures where this could happen. Still, my
knowledge is limited; if there is one, feel free to send me a mail and I
will update the test accordingly.
Adding insult to injury, this test can fail in various funny ways with VMs:
- under x86 QEMU, no trap() happens. As ring 3 code stays almost untouched by
QEMU VMM, I suppose the exception can only be triggered when the host
itself is capable of catching unaligned accesses.
- under Virtual Box with HVM support, i386 works fine, but amd64 fails with a
SIGILL (Illegal instruction) that happens right before entering the
signal handler. No idea why, and trying to debug it with gdb freezes the VM
(including ddb breaks).
Anyway, tested with:
- i386: P4 host, anita, Virtual Box HVM (Mac OS X)
- amd64: anita, Virtual Box HVM (Mac OS X)
XXX I would appreciate if someone could test it under a real amd64 host with
an up-to-date kernel, so I can reasonably assume that the culprit is
Virtual Box and not our amd64 port (my test machine being off line
I cannot do it myself). Results from other arches would be a plus too.
Initial issue reported by Nicolas Joly on port-amd64. Thanks!
- always provide a vmspace for the new proc, initially borrowing from proc0
(this part fixes PR 46286)
- increase parallelism between parent and child if arguments allow this,
avoiding a potential deadlock on exec_lock
- add a new flag for userland to request old (lockstepped) behaviour for
better error reporting
- adapt test cases to the previous two and add a new variant to test the
diagnostics flag
- fix a few memory (and lock) leaks
- provide netbsd32 compat
