i386 vsyscall support (vdso-provided sysenter/syscall instruction based)

this doubles the performance of the fastest syscalls on the atom I
tested it on; improvement is reportedly much more dramatic on
worst-case cpus. cannot be used for cancellable syscalls.
avoid the thread-ptr-init behavior of sigaction when not installing handler

this is necessary because posix_spawn calls sigaction after vfork, and
if the thread pointer is not already initialized, initializing it in
the child corrupts the parent process's state.
comment possibly-confusing i386 vsyscall asm
remove dead code from dynamic linker
fix namespace clash (libc) in dynlink.c

this makes it so the #undef libc and __libc name are no longer needed,
which were problematic because the "accessor function" mode for
accessing the libc struct could not be used, breaking build on any
compiler without (working) visibility.
ensure pointer decay in inline-asm arg for i386 syscall6

this is actually a rather subtle issue: do arrays decay to pointers
when used as inline asm args? gcc says yes, but currently pcc says no.
hopefully this discrepency in pcc will be fixed, but since the
behavior is not clearly defined anywhere I can find, I'm using an
explicit operation to cause the decay to occur.
workaround broken hidden-visibility handling in pcc

with this change, pcc-built musl libc.so seems to work correctly. the
problem is that pcc generates GOT lookups for external-linkage symbols
even if they are hidden, rather than using GOT-relative addressing.
the entire reason we're using hidden visibility on the __libc object
is to make it accessible prior to relocations -- not to mention
inexpensive to access. unfortunately, the workaround makes it even
more expensive on pcc.

when the pcc issue is fixed, an appropriate version test should be
added so new pcc can use the much more efficient variant.
fix main program TLS alignment for dynamic-linked programs

this change brings the behavior in line with the static-linked code,
which seems to be correct.
fix overlap of thread stacks with thread tls segments
block uid/gid changes during posix_spawn

usage of vfork creates a situation where a process of lower privilege
may momentarily have write access to the memory of a process of higher
privilege.

consider the case of a multi-threaded suid program which is calling
posix_spawn in one thread while another thread drops the elevated
privileges then runs untrusted (relative to the elevated privilege)
code as the original invoking user. this untrusted code can then
potentially modify the data the child process will use before calling
exec, for example changing the pathname or arguments that will be
passed to exec.

note that if vfork is implemented as fork, the lock will not be held
until the child execs, but since memory is not shared it does not
matter.
add support for TLS variant I, presently needed for arm and mips

despite documentation that makes it sound a lot different, the only
ABI-constraint difference between TLS variants II and I seems to be
that variant II stores the initial TLS segment immediately below the
thread pointer (i.e. the thread pointer points to the end of it) and
variant I stores the initial TLS segment above the thread pointer,
requiring the thread descriptor to be stored below. the actual value
stored in the thread pointer register also tends to have per-arch
random offsets applied to it for silly micro-optimization purposes.

with these changes applied, TLS should be basically working on all
supported archs except microblaze. I'm still working on getting the
necessary information and a working toolchain that can build TLS
binaries for microblaze, but in theory, static-linked programs with
TLS and dynamic-linked programs where only the main executable uses
TLS should already work on microblaze.

alignment constraints have not yet been heavily tested, so it's
possible that this code does not always align TLS segments correctly
on archs that need TLS variant I.
microblaze TLS relocation support, completely untested
add memmem function (gnu extension)

based on strstr. passes gnulib tests and a few quick checks of my own.