these limits could definitely use review, but for now, i feel
consistency and erring on the side of preventing servers from getting
bogged down by excessively-slow user-provided settings (think
.htpasswd) are the best policy. blowfish should be updated to match.

based on versions sent to the list by nsz, with some simplification
and debloating. i'd still like to get them a bit smaller, or ideally
merge them into a single file with most of the code being shared, but
that can be done later.

if needed for debugging, it will be output in the .debug_frame section
instead, where it is not part of the loaded program and where the
strip command is free to strip it.

based on patches submitted by boris brezillon. this commit also fixes
the issue whereby the main application and libc don't have the address
ranges of their mappings stored, which was theoretically a problem for
RTLD_NEXT support in dlsym; it didn't actually matter because libc
never calls dlsym, and it seemed to be doing the right thing (by
chance) for symbols in the main program as well.

based on Gregor's patch sent to the list. includes:
- stdalign.h
- removing gets in C11 mode
- adding aligned_alloc and adjusting other functions to use it
- adding 'x' flag to fopen for exclusive mode

wrong hash was being passed; just a copy/paste error. did not affect
lookups in the global namespace; this is probably why it was not
caught in testing.

previously, this usage could lead to a crash if the thread pointer was
still uninitialized, and otherwise would just cause the canary to be
zero (less secure).

based on the patches contributed by boris brezillon.

before, only the first library that failed to load or symbol that
failed to resolve was reported, and then the dynamic linker
immediately exited. when attempting to fix a library compatibility
issue, this is about the worst possible behavior. now we print all
errors as they occur and exit at the very end if errors were
encountered.

it's naturally aligned when entered with the kernel argv array, but if
ld.so has been invoked explicitly to run a program, the stack will not
be aligned due to having thrown away argv[0].

patch by Luca Barbato (lu_zero)

if new shared mappings of files/devices/shared memory can be made
between the time a robust mutex is unlocked and its subsequent removal
from the pending slot in the robustlist header, the kernel can
inadvertently corrupt data in the newly-mapped pages when the process
terminates. i am fixing the bug by using the same global vm lock
mechanism that was used to fix the race condition with unmapping
barriers after pthread_barrier_wait returns.

this affects at least the case of very long inputs, but may also
affect shorter inputs that become long due to growth while upscaling.
basically, the logic for the circular buffer indices of the initial
base-10^9 digit and the slot one past the final digit, and for
simplicity of the loop logic, assumes an invariant that they're not
equal. the upscale loop, which can increase the length of the
base-10^9 representation, attempted to preserve this invariant, but
was actually only ensuring that the end index did not loop around past
the start index, not that the two never become equal.

the main (only?) effect of this bug was that subsequent logic treats
the excessively long number as having no digits, leading to junk
results.

with this patch, setting _POSIX_SOURCE, or setting _POSIX_C_SOURCE or
_XOPEN_SOURCE to an old version, will bring back the interfaces that
were removed in POSIX 2008 - at least the ones i've covered so far,
which are gethostby*, usleep, and ualarm. if there are other functions
still in widespread use that were removed for which similar changes
would be beneficial, they can be added just like this.

not sure why these were originally omitted..

this function never existed historically; since the float/double
functions it's based on are nonstandard and deprecated, there's really
no justification for its existence except that glibc has it. it can be
added back if there's ever really a need...

linux guarantees ll/sc are always available. on mips1, they will be
emulated by the kernel. thus they are part of the linux mips1 abi and
safe to use.