these were left in glibc for binary compatibility after the public
part of the interface was removed, and libcap kept using them (with
its own copy of the header files) rather than just making the syscalls
directly. might as well add them since they're so small...

i originally omitted these (optional, per POSIX) interfaces because i
considered them backwards implementation details. however, someone
later brought to my attention a fairly legitimate use case: allocating
thread stacks in memory that's setup for sharing and/or fast transfer
between CPU and GPU so that the thread can move data to a GPU directly
from automatic-storage buffers without having to go through additional
buffer copies.

perhaps there are other situations in which these interfaces are
useful too.

the types of these expressions must match the integer promotions.
unsigned 8- and 16-bit values promote to signed int, not unsigned int.

signedness issue kept %ls with no precision from working at all

printf was not printing too many characters, but it was reading one
too many wchar_t elements from the input. this could lead to crashes
if running off the page, or spurious failure if the conversion of the
extra wchar_t resulted in EILSEQ.

this broke the busybox "free" utility (memory reporting) and possibly
other things like uptime.

the field width limit was not being cleared before reading the
literal, causing spurious failures in scanf in cases like "%2d:"
scanning "00:".

this issue affects the last gpl2 version of binutils, which some
people are still using out of aversion to gpl3. musl requires
-Bsymbolic-functions because it's the only way to make a libc.so
that's able to operate prior to dynamic linking but that still behaves
correctly with respect to global vars that may be moved to the main
program via copy relocations.

it's possible that the user has provided a compiler that does not have
any libc to link to, so linking a main program is a bad idea. instead,
generate an empty shared library with no dependencies.

in theory we could support stack protector in the libc itself, and
users wanting to experiment with such usage could add
-fstack-protector to CFLAGS intentionally. but to avoid breakage in
the default case, override broken distro-patched gcc that forces stack
protector on.

some broken distro-provided toolchains have modified gcc to produce
only "gnu hash" dynamic hash table by default. as this is unsupported
by musl, that results in a non-working libc.so. we detect and switch
this on in configure rather than hard-coding it in the Makefile
because it's not supported by old binutils versions, but that might
not even be relevant since old binutils versions already fail from
-Bsymbolic-functions being missing. at some point I may review whether
this should just go in the Makefile...

this is not tested yet, but should work to get rid of unwanted
--hash-style=gnu hacks present in some distro-patched gcc versions.

the error will propagate up and be printed to the user at program
start time; at runtime, dlopen will just fail and leave a message for
dlerror.

previously, if mprotect failed, subsequent attempts to perform
relocations would crash the program. this was resulting in an
increasing number of false bug reports on grsec systems where rwx
permission is not possible in cases where users were wrongly
attempting to use non-PIC code in shared libraries. supporting that
usage is in theory possible, but the x86_64 toolchain does not even
support textrels, and the cost of keeping around the necessary
information to handle textrels without rwx permissions is
disproportionate to the benefit (which is essentially just supporting
broken library setups on grsec machines).

also, i unified the error-out code in map_library now that there are 3
places from which munmap might have to be called.

this is ugly and stupid, but now that the *64 symbol names exist, a
lot of broken GNU software detects them in configure, then either
breaks during build due to missing off64_t definition, or attempts to
compile without function declarations/prototypes. "fixing" it here is
easier than telling everyone to add yet another feature test macro to
their builds.

Per POSIX, "The abort() function shall cause abnormal process
termination to occur, unless the signal SIGABRT is being caught and
the signal handler does not return."

If SIGABRT is blocked or if a signal handler is installed and does
return, abort is still required to cause abnormal program termination.
We cannot use a_crash() to do this, since a SIGILL handler could also
be installed (and might even longjmp out of the abort, not expecting
to be invoked from within abort), nor can we rely on resetting the
signal handler and re-raising the signal (this has race conditions in
multi-threaded programs). On the other hand, SIGKILL is a perfectly
safe, unblockable way to obtain abnormal program termination, and it
requires no ugly loop-and-retry logic.

for some nonsensical reason, glibc's headers use inline functions that
redirect some of the standard functions to ugly nonstandard names (and
likewise for some of their nonstandard functions).

I've been looking for data that would suggest a good default, and
since little has shown up, i'm doing this based on the limited data I
have. the value 80k is chosen to accommodate 64k of application data
(which happens to be the size of the buffer in git that made it crash
without a patch to call pthread_attr_setstacksize) plus the max stack
usage of most libc functions (with a few exceptions like crypt, which
will be fixed soon to avoid excessive stack usage, and [n]ftw, which
inherently uses a fair bit in recursive directory searching).

if further evidence emerges suggesting that the default should be
larger, I'll consider changing it again, but I'd like to avoid it
getting too large to avoid the issues of large commit charge and rapid
address space exhaustion on 32-bit machines.

this fix is necessary because a program could be started with some of
the implementation-reserved signals masked (e.g. due to exec having
been called from a signal handler, or from a non-musl program) and
then could obtain an invalid-to-use-later sigset_t as the old/saved
signal mask.

this action is now performed in pthread_self initialization; it must
be performed there in case the first call to pthread_create is from a
signal handler, in which case the old signal mask could be restored on
return from the signal.

this should be the last major fix needed to support running
glibc-linked conforming POSIX programs with musl in place of glibc, as
long as musl provides the features they need and they don't use
pthread cancellation (which is implemented as c++ exceptions in glibc,
and fundamentally incompatible with musl).

lots of broken programs expect this, and it's gotten to the point of
being a troubleshooting FAQ topic. best to just fix it.

this was fixed previously on i386 but the corresponding code on x86_64
was missed.

these will NOT be used when compiling with -D_LARGEFILE64_SOURCE on
musl; instead, they exist in the hopes of eventually being able to run
some glibc-linked apps with musl sitting in place of glibc.

also remove the (apparently incorrect) fcntl alias.

linking the wrong crt1.o resulted in textrels and thus crashing

no idea where I got the idea fpurge should exist...

also fix up distinction of what is GNU-only and what's GNU+BSD

two actual issues: one is that __dynlink no longer wants/needs a GOT
pointer argument, so the code to generate that argument can be
removed. the other issue was that in the i386 code, argc/argv were
being loaded into registers that would be call-clobbered, then copied
to preserved registers, rather than just being loaded into the proper
call-preserved registers to begin with.

this cleanup is in preparation for adding new dynamic linker
functionality (ability to explicitly invoke the dynamic linker to run
a program).

bug report and solution by Richard Pennington

issue reported by Richard Pennington; slightly simpler fix applied