this was missed in the previous commit.

the excess space was unused and unintentional. this change does not
affect the ABI between applications and libc. while it does
theoretically affect linkage between third-party translation units
using jmp_buf as part of a structure, we've already changed jmp_buf at
least once on all archs, and problems were never observed, likely
because such usage would be very unusual. in any case it's best to get
things right now rather than making changes sometime during the 1.0.x
series or later.

this seems to have been copied erroneously from the arm version of the
file. it's fairly harmless but it's a mistake and better to fix now
than later.

on x32, this change allows programs which use syscall() with pointers
or 64-bit values as arguments to work correctly, i.e. without
truncation or incorrect sign extension. on all other supported archs,
syscall_arg_t is defined as long, so this change is a no-op.

the previous pattern required "x32" to be used as the second field of
the gcc tuple, which is usually reserved for vendor use and not
appropriate as an ABI specifier. with this change, putting "x32" at
the end of the tuple, the way ABI specifiers are normally done, is
also permitted.

the omission of the padding was uncovered by the latest regression
statvfs regression test added to libc-test.

the incorrect error codes also made their way into errno when
__ptsname_r was called by plain ptsname, which reports errors via
errno rather than a return value.

Applications ended up with copy relocations for this array, which
resulted in libc's references to this array pointing to the
application's copy.  The dynamic linker, however, can require this array
before the application is relocated, and therefore before the
application's copy of this array is initialized.  This resulted in
garbage being loaded into FPSCR before executing main, which violated
the ABI.

We fix this by putting the array in crt1 and making the libc copy
private.  This prevents libc's reference to the array from pointing to
an uninitialized copy in the application.

it's UB to fetch variadic args when none are passed, and this caused
real crashes on ppc due to its calling convention, which defines that
for variadic functions aggregate types be passed as pointers.
the assignment caused that pointer to get dereferenced, resulting in
a crash.

The mips statfs struct layout is different than on other archs, so the
statfs, fstatfs, statvfs and fstatvfs APIs were broken on mips.
Now the ordering is fixed, the types are kept consistent with other archs.

This used to be broken when all archs had the same semid_ds definition:
there is no padding around the time_t members on mips.

these were incorrectly copied from the kernel, whose ABI matches the
POSIX requirements but with the wrong underlying types and wrong
signedness.

these have been wrong for a long time and were never detected or
corrected. powerpc needs some gratuitous extra padding/reserved slots
in ipc_perm, big-endian ordering for the padding of time_t slots that
was intended by the kernel folks to allow a transition to 64-bit
time_t, and some minor gratuitous reordering of struct members.

the definition was found to be incorrect at least for powerpc, and
fixing this cleanly requires making the definition arch-specific. this
will allow cleaning up the definition for other archs to make it more
specific, and reversing some of the ugliness (time_t hacks) introduced
with the x32 port.

this first commit simply copies the existing definition to each arch
without any changes. this is intentional, to make it easier to review
changes made on a per-arch basis.

Remove non-constant aggregate initializer. (Still using long long, but
that is supported by ancient compilers without __extension__ anyway).

the printf floating point formatting code contains an optimization to
avoid computing digits that will be thrown away by rounding at the
specified (or default) precision. while it was correctly retaining all
places up to the last decimal place to be printed, it was not
retaining enough precision to see the next nonzero decimal place in
all cases. this could cause incorrect rounding down in round-to-even
(default) rounding mode, for example, when printing 0.5+DBL_EPSILON
with "%.0f".

in the fix, LDBL_MANT_DIG/3 is a lazy (non-sharp) upper bound on the
number of zeros between any two nonzero decimal digits.

empirically the overflow was an off-by-one, and it did not seem to be
overwriting meaningful data. rather than simply increasing the buffer
size by one, however, I have attempted to make the size obviously
correct in terms of bounds on the number of iterations for the loops
that fill the buffer. this still results in no more than a negligible
size increase of the buffer on the stack (6-7 32-bit slots) and is a
"safer" fix unless/until somebody wants to do the proof that a smaller
buffer would suffice.

this was problematic because several archs don't define __WORDSIZE. we
could add it, but I would rather phase this macro out in the long
term. in our version of the headers, UINTPTR_MAX is available here, so
just use it instead.

this seems to have been overlooked, and resulted in breakage in
anything including sys/user.h.

neither is correct; different commands take different argument types,
and some take no arguments at all. I have a much larger overhaul of
fcntl prepared to address this, but it's not appropriate to commit
during freeze.

the immediate problem being addressed affects forward-compatibility on
x32: if new commands are added and they take pointers, but the
libc-level fcntl function is not aware of them, using long would
sign-extend the pointer to 64 bits and give the kernel an invalid
pointer. on the kernel side, the argument to fcntl is always treated
as unsigned long, so no harm is done by treating possibly-signed
integer arguments as unsigned. for every command that takes an integer
argument except for F_SETOWN, large integer arguments and negative
arguments are handled identically anyway. in the case of F_SETOWN, the
kernel is responsible for converting the argument which it received as
unsigned long to int, so the sign of negative arguments is recovered.

the other problem that will be addressed later is that the type passed
to va_arg does not match the type in the caller of fcntl. an advanced
compiler doing cross-translation-unit analysis could potentially see
this mismatch and issue warnings or otherwise make trouble.

on i386, this patch was confirmed not to alter the code generated by
gcc 4.7.3. in principle the generated code should not be affected on
any arch except x32.

the kernel uses long longs in the struct, but the documentation
says they're long. so we need to fixup the mismatch between the
userspace and kernelspace structs.
since the struct offers a mem_unit member, we can avoid truncation
by adjusting that value.

if we ever encounter other targets where error codes don't fit in the
8-bit range, the table should probably just be bumped to 16-bit, but
for now I don't want to increase the table size on all archs just
because of a bug in the mips abi.

most notably, it was failing to match sh4-*, etc., but in general the
explicit matching of hyphens for some archs was problematic because it
failed to accept simply the musl-style arch name (without a gcc-style
tuple) as an input. the original motivation of matching hyphens was to
prevent incorrectly identifying a 64-bit arch as the corresponding
32-bit arch (e.g. mips* matching mips64) but this is easily fixed by
simply checking (and for now, rejecting as unsupported) the relevant
64-bit archs.

default endianness for sh on linux is little, and while conventions
vary, "eb" seems to be the most widely used suffix for big endian.

linux, gcc, etc. all use "sh" as the name for the superh arch. there
was already some inconsistency internally in musl: the dynamic linker
was searching for "ld-musl-sh.path" as its path file despite its own
name being "ld-musl-superh.so.1". there was some sentiment in both
directions as to how to resolve the inconsistency, but overall "sh"
was favored.

per POSIX, ENOENT is reserved for invalid stream position; it is an
optional error and would only happen if the application performs
invalid seeks on the underlying file descriptor. however, linux's
getdents syscall also returns ENOENT if the directory was removed
between the time it was opened and the time of the read. we need to
catch this case and remap it to simple end-of-file condition (null
pointer return value like an error, but no change to errno). this
issue reportedly affects GNU make in certain corner cases.

rather than backing up and restoring errno, I've just changed the
syscall to be made in a way that doesn't affect errno (via an inline
syscall rather than a call to the __getdents function). the latter
still exists for the purpose of providing the public getdents alias
which sets errno.

introduced in linux v3.13, 482fc6094afad572a4ea1fd722e7b11ca72022a0
to mitigate dns cache poisoning via fragmentation

for High-availability Seamless Redundancy (HSR) specified in IEC 62439-3
new in linux v3.13, f421436a591d34fa5279b54a96ac07d70250cc8d

introduced in linux v3.13, 62748f32d501f5d3712a7c372bbb92abc7c62bc7

see glibc commit 9c21573c02446b3d5cf6a34b67c8545e5be6a600

the build system has no automatic way to know this code applies to
both big (default) and little endian variants, so explicit .sub files
are needed.

Userspace emulated floating-point (gcc -msoft-float) is not compatible
with the default mips abi (assumes an FPU or in kernel emulation of it).
Soft vs hard float abi should not be mixed, __mips_soft_float is checked
in musl's configure script and there is no runtime check. The -sf subarch
does not save/restore floating-point registers in setjmp/longjmp and only
provides dummy fenv implementation.

the reordering of headers caused some risc archs to not see
the __syscall declaration anymore.
this caused build errors on mips with any compiler,
and on arm and microblaze with clang.

we now declare it locally just like the powerpc port does.

previously it was wrongly using the x86_64 one, precluding having both
x32 and x86_64 libs present on the same system.