something is wrong with the logic for the argument layout, resulting
in compile errors on mips due to too many args to syscall... further
information on how it's supposed to work will be needed before it can
be reactivated.

based on patch by Justin Cormack

previously, it was pretty much random which one of these trees a given
function appeared in. they have now been organized into:

src/linux: non-POSIX linux syscalls (possibly shard with other nixen)
src/legacy: various obsolete/legacy functions, mostly wrappers
src/misc: still mostly uncategorized; some misc POSIX, some nonstd
src/crypt: crypt hash functions

further cleanup will be done later.

note that POSIX does not specify these functions as _Noreturn, because
POSIX is aligned with C99, not the new C11 standard. when POSIX is
eventually updated to C11, it will almost surely give these functions
the _Noreturn attribute. for now, the actual _Noreturn keyword is not
used anyway when compiling with a c99 compiler, which is what POSIX
requires; the GCC __attribute__ is used instead if it's available,
however.

in a few places, I've added infinite for loops at the end of _Noreturn
functions to silence compiler warnings. presumably
__buildin_unreachable could achieve the same thing, but it would only
work on newer GCCs and would not be portable. the loops should have
near-zero code size cost anyway.

like the previous _Noreturn commit, this one is based on patches
contributed by philomath.

not sure why these were originally omitted..

some minor changes to how hard-coded sets for thread-related purposes
are handled were also needed, since the old object sizes were not
necessarily sufficient. things have gotten a bit ugly in this area,
and i think a cleanup is in order at some point, but for now the goal
is just to get the code working on all supported archs including mips,
which was badly broken by linux rejecting syscalls with the wrong
sigset_t size.

based on patches by orc and Isaac Dunham, with some fixes. sys/io.h
exists and contains prototypes for these functions regardless of
whether the target arch has them; this is a bit unorthodox but I don't
think it will break anything. the function definitions do not exist
unless the appropriate SYS_* syscall number macro is defined, which
should make sure configure scripts looking for these functions don't
find them on other systems.

presently, sys/io.h does not have the inb/outb/etc. port io
macros/functions. I'd be surprised if ioperm/iopl are useful without
them, so they probably need to be added at some point in appropriate
bits/io.h files...

based on patches by orc and Isaac Dunham.

based on patch by orc and Isaac Dunham, with some fixes.

based on patch by orc and Isaac Dunham, with some details fixed.

based on a patch submitted by Kristian L. <email@thexception.net>

request/patch by william haddonthethird, slightly modifed to add
_GNU_SOURCE feature test macro so that the compiler can verify the
prototype matches.

these are not exposed publicly in any header, but the few programs
that use them (modutils/kmod, etc.) are declaring the functions
themselves rather than making the syscalls directly, and it doesn't
really hurt to have them (same as the capset junk).

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...

- add the rest of the junk traditionally in sys/param.h
- add prototypes for some nonstandard functions
- add _GNU_SOURCE to their source files so the compiler can check proto

presumably broken gcc may generate calls to these, and it's said that
ffmpeg makes use of sincosf.

patch by Jeremy Huntwork

seeking back can be performed by the caller, but if the caller doesn't
expect it, it will result in an infinite loop of failures.

not sure if this is correct/ideal. it needs further attention.

the changes to syscall_ret are mostly no-ops in the generated code,
just cleanup of type issues and removal of some implementation-defined
behavior. the one exception is the change in the comparison value,
which is fixed so that 0xf...f000 (which in principle could be a valid
return value for mmap, although probably never in reality) is not
treated as an error return.

it should be noted that flock does not mix well with standard fcntl
locking, but nonetheless some applications will attempt to use flock
instead of fcntl if both exist. options to configure or small patches
may be needed. debian maintainers have plenty of experience with this
unfortunate situation...

somehow this worked on my simple fstab, but horribly broke in general,
leading to use of uninitialized offset array and crashes.