this type was removed back in 5243e5f1 ,
because it was removed from the XSI specs.
however some apps use it.
since it's in the POSIX reserved namespace, we can expose it
unconditionally.

and remove syscall todos from microblaze

SO_REUSEPORT implementation was merged in the linux kernel commit
c617f398edd4db2b8567a28e899a88f8f574798d 2013-01-23

the issue at hand is that many syscalls require as an argument the
kernel-ABI size of sigset_t, intended to allow the kernel to switch to
a larger sigset_t in the future. previously, each arch was defining
this size in syscall_arch.h, which was redundant with the definition
of _NSIG in bits/signal.h. as it's used in some not-quite-portable
application code as well, _NSIG is much more likely to be recognized
and understood immediately by someone reading the code, and it's also
shorter and less cluttered.

note that _NSIG is actually 65/129, not 64/128, but the division takes
care of throwing away the off-by-one part.

reportedly some programs (e.g. showkeys in the kbd package) use it.

wctype_t was incorrectly "int" rather than "long" on x86_64. not only
is this an ABI incompatibility; it's also a major design flaw if we
ever wanted wctype_t to be implemented as a pointer, which would be
necessary if locales support custom character classes, since int is
too small to store a converted pointer. this commit fixes wctype_t to
be unsigned long on all archs, matching the LSB ABI; this change does
not matter for C code, but for C++ it affects mangling.

the same issue applied to wctrans_t. glibc/LSB defines this type as
const __int32_t *, but since no such definition is visible, I've just
expanded the definition, int, everywhere.

it would be nice if these types (which don't vary by arch) could be in
wctype.h, but the OB XSI requirement in POSIX that wchar.h expose some
types and functions from wctype.h precludes doing so. glibc works
around this with some hideous hacks, but trying to duplicate that
would go against the intent of musl's headers.

x86_64 does not have excess precision, at all

arm eabi requires this symbol for static C++ dtors.
usually it is provided by libstdc++, but when a C++ program
doesn't use the std lib (free-standing), the libc has to provide
it.
this was encountered while building transmission, which
depends on such a C++ library (libutp).

this function is nearly identical to __cxa_atexit, but it has the
order of argumens swapped for "performance reasons".
see page 25 of

 http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf

there are other aeabi specific C++ support functions missing, but
it is not clear yet that GCC makes use of them so we omit them for
the moment.

mips and powerpc already had this termios flag defined

it was already defined for mips, but was missing from other archs

they were accidentally exposed under just baseline POSIX, which is a
big namespace pollution issue. thankfully glibc only exposes them
under _GNU_SOURCE, not under any of its other options, so omitting
the pollution in the default _BSD_SOURCE profile does not hurt
application compatibility at all.

glibc exposes them from ucontext.h.
since that header includes signal.h, it is safe to put them
into bits/signal.h, if _GNU_SOURCE is defined.

these are also needed by qemu.

both kernel and glibc define it only on x86(_64).

this is needed for qemu, and since it differs for each arch
it can't be circumvented easily by using a macro in CFLAGS.

if these are to be supported, they belong in the main stat.h, not
repeated for each arch.

these structures are purely for use by trace/debug tools and tools
working with core files. the definition of fpregset_t, which was
previously here, has been removed because it was wrong; fpregset_t
should be the type used in mcontext_t, not the type used in
ptrace/core stuff.

aside from microblaze, these should be roughly correct for all archs
now. some misc junk macros and typedefs are missing, which should
probably be added for max compatibility with trace/debug tools.

it should now really match the kernel. some of the removed padding
corresponded to the difference between user and kernel sigset_t. the
space at the end was redundant with the uc_mcontext member and seems
to have been added as a result of misunderstanding glibc's definition
versus the kernel's.

with these changes, the members/types of mcontext_t and related stuff
should closely match the glibc definitions. unlike glibc, however, the
definitions here avoid using typedefs as much as possible and work
directly with the underlying types, to minimize namespace pollution
from signal.h in the default (_BSD_SOURCE) profile.

this is a first step in improving compatibility with applications
which poke at context/register information -- mainly debuggers, trace
utilities, etc. additional definitions in ucontext.h and other headers
may be needed later.

if feature test macros are used to request a conforming namespace,
mcontext_t is replaced with an opaque structure of the equivalent size
and alignment; conforming programs cannot examine its contents anyway.

these fields were wrongly copied from the kernel's ppc64 struct def

unlike the previous definition, NSIG/_NSIG is supposed to be one more
than the highest signal number. adding this will allow simplifying
libc-internal code that makes signal-related syscalls, which can be
done as a later step. some apps might use it too; while this usage is
questionable, it's at least not insane.

also handle the non-GNUC case where alignment attribute is not available
by simply omitting it. this will not cause problems except for
inclusion of mcontex_t/ucontext_t in application-defined structures,
since the natural alignment of the uc_mcontext member relative to the
start of ucontext_t is already correct. and shame on whoever designed
this for making it impossible to satisfy the ABI requirements without
GNUC extensions.

apparently some other archs have sys/io.h and should not break just
because they don't have the x86 port io functions. provide a blank
bits/io.h everywhere for now.

based on proposal by Isaac Dunham. nonexistance of bits/io.h will
cause inclusion of sys/io.h to produce an error on archs that are not
supposed to have it. this is probably the desired behavior, but the
error message may be a bit unusual.