the TLS pointer, therefore wrecking the pthread environement.
Some ports had _UC_TLSBASE flag or equivalent (_UC_UNIQUE on alpha)
that controlled whether setcontext() would change the TLS pointer.
This change let libpthread override setcontext() with its own version
that unsets _UC_TLSBASE, enabling safe usage of setcontext() with
-lpthread.
We also have the following required changes here:
- rename alpha's _UC_UNIQUE into _UC_TLSBASE
- add _UC_TLSBASE definition in header file for all ports
(powerpc, sh3, sparc and sparc64 lack the implementation for now)
- introduce a libc stub that can be overriden for setcontext()
- modify MD libcs swapcontext() implementations so that they use the
setcontext() libc stub instead of doing a plain system call.
While we are there:
- document various MD _UC_* flags in header file
- add libc and libpthread tests for swapcontext() behavior
(hopefully helpful to spot MD problems introduced with this change)
Future work:
- Deciding whether kernel support or _UC_TLSBASE should be added for
powerpc, sh3, sparc and sparc64 is left to portmasters
sparc64
Approved by core@
- Merge h_regex_att (att.c) and t_regex_att.sh into a single C test program.
The former was really a test program, and the latter just a very strange
driver for it.
- Stop using awk to generate the shell test programs. This is unnecessary
and confusing. Instead, change t_regex.sh to generate the test case
functions on the fly with eval (as done in many other places).
limits (often way too high) and skipping the test case if in doubt,
raise the limits as far as we can, and fix a few places in the test where
we could run into the limits and either skip or fail with a reasonable
message.
assertion failure (and thus a crash in DIAGNOSTIC kernels). Independently
discovered by YAMAMOTO Takashi and Joel Sing.
To avoid this, introduce a cpu_mcontext_validate() function and move all
sanity checks from cpu_setmcontext() there. Also untangle the netbsd32
compat mess slightly and add a cpu_mcontext32_validate() cousin there.
Add an exhaustive atf test case, based partly on code from Joel Sing.
Should finally fix the remaining open part of PR kern/43903.
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!
