make __socketcall analogous to __syscall, error-returning

the __socketcall and __socketcall_cp macros are remnants from a really
old version of the syscall-mechanism infrastructure, and don't follow
the pattern that the "__" version of the macro returns the raw negated
error number rather than setting errno and returning -1.

for time64 purposes, some socket syscalls will need to operate on the
error value rather than returning immediately, so fix this up so they
can use it.

sysvipc: overhaul {sem,shm,msg}ctl for time64

being "ctl" functions that take command numbers, these will be handled
like ioctl/sockopt/etc., using new command numbers for the time64
variants with an "IPC_TIME64" bit added to their values. to obtain
such a reserved bit, we reuse the IPC_64 bit, 0x100, which served only
as part of the libc-to-kernel interface, not as a public interface of
the libc functions.

using new command numbers avoids the need for compat shims (in ABIs
doing time64 through symbol redirection and compat shims) and, by
virtue of having a fixed time64 bit for all commands, we can ensure
that libc can perform the appropriate translations, even if the
application is using new commands from a newer version of the libc
headers than the libc available at runtime.

for the vast majority of 32-bit archs, the kernel {sem,shm,msq}id64_ds
definitions left padding space intended for expanding their time_t
fields to 64 bits in-place, and it would have been really nice to be
able to do time64 support that way. however the padding was almost
always in little-endian order (except on powerpc, and for msqid_ds
only on mips, where it matched the arch's byte order), and more
importantly, the alignment was overlooked. in semid_ds and msqid_ds,
the time_t members were not suitably aligned to be expanded to 64-bit,
due to the ipc_perm header consisting of 9 32-bit words -- except on
powerpc where ipc_perm contains an extra padding word. in shmid_ds,
the time_t members were suitably aligned, except that mips
(accidentally?) omitted the padding for them alltogether.

as a result, we're stuck with adding new time_t fields on the end of
the structures, and assembling the 32-bit lo/hi parts (or 16-bit hi
parts, for mips shmid_ds, which lacked sufficient reserved space for
full 32-bit hi parts) to fill them in.

all of the functional changes here are conditional on the IPC_TIME64
macro having a nonzero definition, which will only happen when
IPC_STAT is redefined for 32-bit archs, and on time_t being larger
than long, so for now the new code is all dead code.

fix semctl with SEM_STAT_ANY

due to the variadic signature, semctl needs to be made aware of any
new commands that take arguments. this was overlooked when commit
af55070eae5438476f921d827b7ae49e8141c3fe added SEM_STAT_ANY.

remove gratuitously-different arch-specific bits/ipc.h files

these differ from generic only in using endian-matched padding with a
short __ipc_perm_seq field in place of the int field in generic. this
is not a documented public interface anyway, and the original intent
was to use int here. some ports just inadvertently slipped in the
kernel short+padding form.

remove arch-specific bits/ipc.h that are identical to generic

previously these differed from generic because they needed their own
definitions of IPC_64. now that it's no longer in public header,
they're identical.

move IPC_64 from public bits/ipc.h to syscall_arch.h

the definition of the IPC_64 macro controls the interface between libc
and the kernel through syscalls; it's not a public API. the meaning is
rather obscure. long ago, Linux's sysvipc *id_ds structures used
16-bit uids/gids and wrong types for a few other fields. this was in
the libc5 era, before glibc. the IPC_64 flag (64 is a misnomer; it's
more like 32) tells the kernel to use the modern[-ish] versions of the
structures.

the definition of IPC_64 has nothing to do with whether the arch is
32- or 64-bit. rather, due to either historical accident or
intentional obnoxiousness, the kernel only accepts and masks off the
0x100 IPC_64 flag conditional on CONFIG_ARCH_WANT_IPC_PARSE_VERSION,
i.e. for archs that want to provide, or that accidentally provided,
both. for archs which don't define this option, no masking is
performed and commands with the 0x100 bit set will fail as invalid. so
ultimately, the definition is just a matter of matching an arbitrary
switch defined per-arch in the kernel.

select: overhaul for time64

major changes are made alongside adding time64 syscall support to
account for issues found during research. select historically accepts
non-normalized (tv_usec not restricted to less than 1000000) timeouts,
and the kernel normalizes them, but the normalization code is buggy
and subject to integer overflows. since normalization is needed anyway
when using SYS_pselect6 or SYS_pselect6_time64 as the backend, simply
do it up-front to eliminate both code path complexity and the
possibility of kernel bugs.

as a side effect, select no longer updates the caller's timeout
timeval with the remaining time. previously, archs that used
SYS_select updated it and archs that used SYS_pselect6 didn't. this
change may turn out to be controversial and may need revisiting, but
in any case the old behavior was not strictly conforming.

POSIX allows modification of the timeout "upon successful completion",
but the Linux syscall modifies it upon unsuccessful completion (EINTR)
as well (and presumably each time the syscall stops and restarts
before it's known whether completion will be successful). it's
possible that this language does not reflect the actual intent of the
standard, since other historical implementations probably behaved like
Linux, but that should be clarified if there's a desire to bring the
old behavior back. regardless, programs that are depending on this are
not correct and are already broken on some archs we support.

recvmmsg: add time64 syscall support, decouple 32-bit time_t

the time64 syscall is used only if the timeout does not fit in 32
bits. after preprocessing, the code is unchanged on 64-bit archs. for
32-bit archs, the timeout now goes through an intermediate copy,
meaning that the caller does not get back the updated timeout. this is
based on my reading of the documentation, which does not document the
updating as a contract you can rely on, and mentions that the whole
recvmmsg timeout mechanism is buggy and unlikely to be useful. if it
turns out that there's interest in making the remaining time
officially available to callers, such functionality could be added
back later.

setitimer, getitimer: decouple time_t from long

these functions have no new time64 syscall, so the existence of a
time64 syscall cannot be used as the condition for the new code.
instead, assume the syscall takes timevals as longs, which is true
everywhere but x32, and interface with the kernel through long[4]
objects.

rather than adding new hacks to special-case x32 here, just add
x32-specific source files since a trivial syscall wrapper suffices
there.

the new code paths added in this commit are statically unreachable on
all current archs, but will become reachable when 32-bit archs get
64-bit time_t.

remove duplicates of new generic bits/msg.h

use 64-bit msqid_ds layout in the generic version of bits/msg.h

this layout is more common already than the old generic, and should
become even more common in the future with new archs added and with
64-bit time_t on 32-bit archs.

duplicate generic bits/msg.h for each arch using it, in prep to change

remove duplicates of new generic bits/sem.h

some of these were not exact duplicates, but had gratuitously
different naming for padding, or omitted the endian checks because the
arch is fixed-endian.

use 64-bit semid_ds layout in the generic version of bits/sem.h

this layout is slightly less common than the old generic one, but only
because x86_64 and x32 wrongly (according to comments in the kernel
headers) copied the i386 padding. for future archs, and with 64-bit
time_t on 32-bit archs, the new layout here will become the most
common, and it makes sense to treat it as the generic.

collapse out byte order conditions in bits/sem.h for fixed-endian archs

having preprocessor conditionals on byte order in the bits headers for
fixed-endian archs is confusing at best. remove them.

duplicate generic bits/sem.h for each arch using it, in prep to change

extricate bits/sem.h from x32 time_t hack

various padding fields in the generic bits/sem.h were defined in terms
of time_t as a cheap hack standing in for "kernel long", to allow x32
to use the generic version of the file. this was a really bad idea, as
it ended up getting copied into lots of arch-specific versions of the
bits file, and is a blocker to changing time_t to 64-bit on 32-bit
archs.

this commit adds an x32-specific version of the header, and changes
padding type back from time_t to long (currently the same type on all
archs but x32) in the generic header and all the others the hack got
copied into.

remove trailing newlines from various versions of bits/shm.h

remove duplicates of new generic bits/shm.h

use 64-bit shmid_ds layout in the generic version of bits/shm.h

this layout is more common already than the old generic, and should
become even more common in the future with new archs added and with
64-bit time_t on 32-bit archs.

the duplicate arch-specific copies are not removed yet in this commit,
so as to assist git tooling in copy/rename tracking.

duplicate generic bits/shm.h for each arch using it, in prep to change

there are more archs sharing the generic 64-bit version of the struct,
which is uniform and much more reasonable, than sharing the current
"generic" one, and depending on how time64 sysvipc is done for 32-bit
archs, even more may be sharing the "64-bit version" in the future.

so, duplicate the current generic to all archs using it (arm, i386,
m68k, microblaze, or1k) so that the generic can be changed freely.

this is recorded as its own commit mainly as a hint to git tooling, to
assist in copy/move tracking.

timerfd: add time64 syscall support, decouple 32-bit time_t

the changes here are semantically and structurally identical to those
made to timer_settime and timer_gettime for time64 support.

sched_rr_get_interval: don't assume time_t is 32-bit on 32-bit archs

as with clock_getres, the time64 syscall for this is not necessary or
useful, this time since scheduling timeslices are not on the order 68
years. if there's a 32-bit syscall, use it and expand the result into
timespec; otherwise there is only one syscall and it does the right
thing to store to timespec directly.

on 64-bit archs, there is no change to the code after preprocessing.

clock_getres: don't assume time_t is 32-bit on 32-bit archs

the time64 syscall for this is not necessary or useful, since clock
resolution is generally better than 68-year granularity. if there's a
32-bit syscall, use it and expand the result into timespec; otherwise
there is only one syscall and it does the right thing to store to
timespec directly.

on 64-bit archs, there is no change to the code after preprocessing.

timer_gettime: add time64 syscall support, decouple 32-bit time_t

the time64 syscall has to be used if time_t is 64-bit, since there's
no way of knowing before making a syscall whether the result will fit
in 32 bits, and the 32-bit syscalls do not report overflow as an
error.

on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the result is now read from the kernel
through long[4] array, then copied into the timespec, to remove the
assumption that time_t is the same as long.

remove x32 syscall timespec fixup hacks

the x32 syscall interfaces treat timespec's tv_nsec member as 64-bit
despite the API type being long and long being 32-bit in the ABI. this
is no problem for syscalls that store timespecs to userspace as
results, but caused uninitialized padding to be misinterpreted as the
high bits in syscalls that take timespecs as input.

since the beginning of the port, we've dealt with this situation with
hacks in syscall_arch.h, and injected between __syscall_cp_c and
__syscall_cp_asm, to special-case the syscall numbers that involve
timespecs as inputs and copy them to a form suitable to pass to the
kernel.

commit 40aa18d55ab763e69ad16d0cf1cebea708ffde47 set the stage for
removal of these hacks by letting us treat the "normal" x32 syscalls
dealing with timespec as if they're x32's "time64" syscalls,
effectively making x32 ax "time64-only 32-bit arch" like riscv32 will
be when it's added. since then, all users of syscalls that x32's
syscall_arch.h had hacks for have been updated to use time64 syscalls,
so the hacks can be removed.

there are still at least a few other timespec-related syscalls broken
on x32, which were overlooked when the x32 hacks were done or added
later. these include at least recvmmsg, adjtimex/clock_adjtime, and
timerfd_settime, and they will be fixed independently later on.

utimensat: add time64 syscall support, decouple 32-bit time_t

time64 syscall is used only if it's the only one defined for the arch,
or if either of the requested times does not fit in 32 bits. care is
taken to normalize the inputs to account for UTIME_NOW or UTIME_OMIT
in tv_nsec, in which case tv_sec should be ignored. this is needed not
only to avoid spurious time64 syscalls that might waste time failing
with ENOSYS, but also to accurately decide whether fallback is
possible.

if the requested time cannot be represented, the function fails with
ENOTSUP, defined in general as "The implementation does not support
the requested feature or value". neither the time64 syscall, nor this
error, can happen on current 32-bit archs where time_t is a 32-bit
type, and both are statically unreachable.

on 64-bit archs, there are only superficial changes to the
SYS_futimesat fallback path, which has been modified to pass long[4]
instead of struct timeval[2] to the kernel, making it suitable for use
on 32-bit archs even once time_t is changed to 64-bit. for 32-bit
archs, the call to SYS_utimensat has also been changed to copy the
timespecs through an array of long[4] rather than passing the
timespec[2] in-place.

clock_settime: add time64 syscall support, decouple 32-bit time_t

time64 syscall is used only if it's the only one defined for the arch,
or if the requested time does not fit in 32 bits. on current 32-bit
archs where time_t is a 32-bit type, this makes it statically
unreachable.

if the time64 syscall is needed because the requested time does not
fit in 32 bits, we define this as an error ENOTSUP, for "The
implementation does not support the requested feature or value".

on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the time is moved through an intermediate
copy to remove the assumption that time_t is a 32-bit type.

timer_settime: add support for time64 syscall, decouple 32-bit time_t

time64 syscall is used only if it's the only one defined for the arch,
if either component of the itimerspec does not fit in 32 bits, or if
time_t is 64-bit and the caller requested the old value, in which case
there's a possibility that the old value might not fit in 32 bits. on
current 32-bit archs where time_t is a 32-bit type, this makes it
statically unreachable.

on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the time is moved through an intermediate
copy to remove the assumption that time_t is a 32-bit type.

pselect, ppoll: add time64 syscall support, decouple 32-bit time_t

time64 syscall is used only if it's the only one defined for the arch,
or if the requested timeout length does not fit in 32 bits. on current
32-bit archs where time_t is a 32-bit type, this makes it statically
unreachable.

on 64-bit archs, there are only superficial changes to the code after
preprocessing. both before and after these changes, these functions
copied their timeout arguments to avoid letting the kernel clobber the
caller's copies. now, the copying also serves to change the type from
userspace timespec to a pair of longs, which makes a difference only
in the 32-bit fallback case, not on 64-bit.

futex wait operations: add time64 syscall support, decouple 32-bit time_t

thanks to the original factorization using the __timedwait function,
there are no FUTEX_WAIT calls anywhere else, giving us a single point
of change to make nearly all the timed thread primitives time64-ready.
the one exception is the FUTEX_LOCK_PI command for PI mutex timedlock.
I haven't tried to make these two points share code, since they have
different fallbacks (no non-private fallback needed for PI since PI
was added later) and FUTEX_LOCK_PI isn't a cancellation point (thus
allowing the whole code path to inline into pthread_mutex_timedlock).

as for other changes in this series, the time64 syscall is used only
if it's the only one defined for the arch, or if the requested timeout
does not fit in 32 bits. on current 32-bit archs where time_t is a
32-bit type, this makes it statically unreachable.

on 64-bit archs, there are only superficial changes to the code after
preprocessing. on current 32-bit archs, the time is passed via an
intermediate copy to remove the assumption that time_t is a 32-bit
type.

semtimedop: add time64 syscall support, decouple 32-bit time_t

time64 syscall is used only if it's the only one defined for the arch,
or if the requested timeout does not fit in 32 bits. on current 32-bit
archs where time_t is a 32-bit type, this makes it statically
unreachable.

on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the time is passed via an intermediate copy
to remove the assumption that time_t is a 32-bit type.

to avoid duplicating SYS_ipc/SYS_semtimedop choice logic, the code for
32-bit archs "falls through" after updating the timeout argument ts to
point to a [compound literal] array of longs. in preparation for
"time64-only" 32-bit archs, an extra case is added for neither SYS_ipc
nor the non-time64 SYS_semtimedop existing; the ENOSYS failure path
here should never be reachable, and is added just in case a compiler
can't see that it's not reachable, to avoid spurious static analysis
complaints.

sigtimedwait: add time64 syscall support, decouple 32-bit time_t

time64 syscall is used only if it's the only one defined for the arch,
or if the requested timeout length does not fit in 32 bits. on current
32-bit archs where time_t is a 32-bit type, this makes it statically
unreachable.

on 64-bit archs, there are only superficial changes to the code after
preprocessing. on current 32-bit archs, the timeout is passed via an
intermediate copy to remove the assumption that time_t is a 32-bit
type.

mq_timedsend, mq_timedreceive: add time64, decouple 32-bit time_t

time64 syscall is used only if it's the only one defined for the arch,
or if the requested absolute timeout does not fit in 32 bits. on
current 32-bit archs where time_t is a 32-bit type, this makes it
statically unreachable.

on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the timeout is passed via an intermediate
copy to remove the assumption that time_t is a 32-bit type.

clock_nanosleep: add time64 syscall support, decouple 32-bit time_t

time64 syscall is used only if it's the only one defined for the arch,
or if the requested time does not fit in 32 bits. on current 32-bit
archs where time_t is a 32-bit type, this makes it statically
unreachable.

on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the time is moved through an intermediate
copy to remove the assumption that time_t is a 32-bit type.

implement settimeofday in terms of clock_settime, not old syscall

this is yet another place where special handling of time syscalls can
and should be avoided by implementing legacy functions in terms of
their modern replacements. in theory a fallback to SYS_settimeofday
could be added to clock_settime, but SYS_clock_settime has been
available since Linux 2.6.0 or earlier, i.e. all the way back to the
minimum supported version.

internally, define plain syscalls, if missing, as their time64 variants

this commit has no effect whatsoever right now, but is in preparation
for a future riscv32 port and other future 32-bit archs that will be
"time64-only" from the start on the kernel side.

together with the previous x32 changes, this commit ensures that
syscall call points that don't care about time (passing null timeouts,
etc.) can continue to do so without having to special-case time64-only
archs, and allows code using the time64 syscalls to uniformly test for
the need to fallback with SYS_foo != SYS_foo_time64, rather than
needing to check defined(SYS_foo) && SYS_foo != SYS_foo_time64.

internally, define time64 syscalls on x32 as the existing syscalls

x32 is odd in that it's the only ILP32 arch/ABI we have where time_t
is 64-bit rather than (32-bit) long, and this has always been
problematic in that it results in struct timespec having unused
padding space, since tv_nsec has type long, which the kernel insists
be zero- or sign-extended (due to negative tv_nsec being invalid, it
doesn't matter which) to match the x86_64 type.

up til now, we've had really ugly hacks in x32/syscall_arch.h to patch
up the timespecs passed to the kernel. but the same requirement to
zero- or sign-extend tv_nsec also applies to all the new time64
syscalls on true 32-bit archs. so let's take advantage of this to
clean things up.

this patch defines all of the time64 syscalls for x32 as aliases for
the existing syscalls by the same name. this establishes the following
invariants:

- if the time64 form is defined, it takes time arguments as 64-bit
  objects, and tv_nsec inputs must be zero-/sign-extended to 64-bit.

- if the time64 form is not defined, or if the time64 form is defined
  and is not equal to the "plain" form, the plain form takes time
  arguments as longs.

this will avoid the need for protocols for archs to define appropriate
types for each family of syscalls, and for the reader of the code to
have to be aware of such type definitions.

in some sense it might be simpler if the plain syscall form were
undefined for x32, so that it would always take longs if defined.
however, a number of these syscalls are used in contexts with a null
time argument, or (e.g. futex) for commands that don't involve time at
all, and having to introduce time64-specific logic to all those call
points does not make sense. thus, while the "plain" forms are kept now
just because they're needed until the affected code is converted over,
they'll also almost surely be kept in the future as well.

don't use futimesat syscall as utimensat fallback on x32

kernel support for x32 was added long after the utimensat syscall was
already available, so having a fallback is just wasted code size.

also, for changes related to time64 support on 32-bit archs, I want to
be able to assume the old futimesat syscall always works with longs,
which is true except for x32. by ensuring that it's not used on x32,
the needed invariant is established.

fix and simplify futimesat fallback in utimensat

previously the fallback wrongly failed with EINVAL rather than ENOSYS
when UTIME_NOW was used with one component but not both. commit
dd5f50da6f6c3df5647e922e47f8568a8896a752 introduced this behavior when
initially adding the fallback support.

instead, detect the case where both are UTIME_NOW early and replace
with a null times pointer; this may improve performance slightly (less
copy from user), and removes the complex logic from the fallback case.
it also makes things slightly simpler for adding time64 code paths.

refactor thrd_sleep and nanosleep in terms of clock_nanosleep

for namespace-safety with thrd_sleep, this requires an alias, which is
also added. this eliminates all but one direct call point for
nanosleep syscalls, and arranges that 64-bit time_t conversion logic
will only need to exist in one file rather than three.

as a bonus, clock_nanosleep with CLOCK_REALTIME and empty flags is now
implemented as SYS_nanosleep, thereby working on older kernels that
may lack POSIX clocks functionality.

use the correct stat structure in the fstat path

commit 01ae3fc6d48f4a45535189b7a6db286535af08ca modified fstatat to
translate the kernel's struct stat ("kstat") into the libc struct stat.
To do this, it created a local kstat object, and copied its contents
into the user-provided object.

However, the commit neglected to update the fstat compatibility path and
its fallbacks. They continued to pass the user-supplied object to the
kernel, later overwiting it with the uninitialized memory in the local
temporary.

refactor adjtime function using adjtimex function instead of syscall

this removes the assumption that userspace struct timex matches the
syscall type and sets the stage for 64-bit time_t on 32-bit archs.

refactor adjtimex in terms of clock_adjtime

this sets the stage for having the conversion logic for 64-bit time_t
all in one file, and as a bonus makes clock_adjtime for CLOCK_REALTIME
work even on kernels too old to have the clock_adjtime syscall.

fix inadvertent introduction of extern object stx

commit dfc81828f7ab41da08f744c44117a1bb20a05749 accidentally defined
an instance of struct statx along with the struct declaration.

implement fstatat with SYS_statx, conditional on undersized kstat time

this commit adds a new backend for fstatat (and thereby the whole stat
family) using the SYS_statx syscall, but conditions the new code on
the kernel stat structure's time fields being smaller than time_t. in
principle that should make it all dead code at present, but mips64 has
a broken stat structure with 32-bit time fields despite having 64-bit
time_t elsewhere, so on mips64 it is a functional change that makes
post-Y2038 filesystem timestamps accessible.

whenever the 32-bit archs end up getting 64-bit time_t, regardless of
how that happens, the changes in this commit will automatically take
effect for them too.

cleanup includes now that stat, lstat no longer make direct syscalls

restore property that fstat(AT_FDCWD) fails with EBADF

AT_FDCWD is not a valid file descriptor, so POSIX requires fstat to
fail with EBADF. if passed to fstatat, the call would spuriously
succeed and return results for the working directory.

remove mips/n32/64 stat struct hacks from syscall machinery

now that we have a kstat structure decoupled from the public struct
stat, we can just use the broken kernel structures directly and let
the code in fstatat do the translation.

decouple struct stat from kernel type

presently, all archs/ABIs have struct stat matching the kernel
stat[64] type, except mips/mipsn32/mips64 which do conversion hacks in
syscall_arch.h to work around bugs in the kernel type. this patch
completely decouples them and adds a translation step to the success
path of fstatat. at present, this is just a gratuitous copying, but it
opens up multiple possibilities for future support for 64-bit time_t
on 32-bit archs and for cleaned-up/unified ABIs.

for clarity, the mips hacks are not yet removed in this commit, so the
mips kstat structs still correspond to the output of the hacks in
their syscall_arch.h files, not the raw kernel type. a subsequent
commit will fix this.

refactor all stat functions in terms of fstatat

equivalent logic for fstat+O_PATH fallback and direct use of
stat/lstat syscalls where appropriate is kept, now in the fstatat
function. this change both improves functionality (now, fstatat forms
equivalent to fstat/lstat/stat will work even on kernels too old to
have the at functions) and localizes direct interfacing with the
kernel stat structure to one file.

remove utterly wrong includes from mips64/n32 bits/stat.h

these were overlooked during review. bits headers are not allowed to
pull in additional headers (note: that rule is currently broken in
other places but just for endian.h). string.h has no place here
anyway, and including bits/alltypes.h without defining macros to
request types from it is a nop.

use register constraint instead of memory operand for riscv64 atomics

the "A" constraint is simply for an address expression that's a single
register, but it's not yet supported by clang, and has no advantage
here over just using a register operand for the address. the latter is
actually preferable in the a_cas_p case because it avoids aliasing an
lvalue onto the memory.

fix riscv64 atomic asm constraints

most egregious problem was the lack of memory clobber and lack of
volatile asm; this made the atomics memory barriers but not compiler
barriers. use of "+r" rather than "=r" for a clobbered temp was also
wrong, since the initial value is indeterminate.

fix riscv64 syscall asm constraint

having "+r"(a0) is redundant with "0"(a0) in syscalls with at least 1
arg, which is arguably a constraint violation (clang treats it as
such), and an invalid input with indeterminate value in the 0-arg
case. use the "=r"(a0) form instead.

fix broken lseek on x32 (x86_64/ILP32) with offsets larger than LONG_MAX

this is analogous to commit 918c5fa0fc656e49b1ab9ce47183a23e3a36bc00
which fixed the corresponding issue for mips n32.

fix broken lseek on mipsn32 with offsets larger than LONG_MAX

mips n32 has 32-bit long, and generally uses long syscall arguments
and return values, but provides only SYS_lseek, not SYS_llseek. we
have some framework (syscall_arg_t, added for x32) to make syscall
arguments 64-bit in such a setting, but it's not clear whether this
could match the sign-extension semantics needed for 32-bit args to all
the other syscalls, and we don't have any existing mechanism to allow
the return value of syscalls to be something other than long.

instead, just provide a custom mipsn32 version of the lseek function
doing its own syscall asm with 64-bit arguments. as a result of commit
03919b26ed41c31876db41f7cee076ced4513fad, stdio will also get the new
code, fixing fseeko/ftello too.

clean up mips64/n32 syscall asm constraints

ever since inline syscalls were added for (o32) mips in commit
328810d32524e4928fec50b57e37e1bf330b2e40, the asm has nonsensically
loaded the syscall number, rather than taking $2 as an input
constraint to let the compiler load it. commit
cfc09b1ecf0c6981494fd73dffe234416f66af10 improved on this somewhat by
allowing a constant syscall number to propagate into an immediate, but
missed that the whole operation made no sense.

now, only $4, $5, $6, $8, and $9 are potential input-only registers.
$2 is always input and output, and $7 is both when it's an argument,
otherwise output-only. previously, $7 was treated as an input (with a
"1" constraint matching its output position) even when it was not an
input, which was arguably undefined behavior (asm input from
indeterminate value). this is corrected.

deduplicate mips64/n32 syscall clobbered register lists

this patch is not purely non-functional changes, since before, $8 and
$9 were wrongly in the clobberlist for syscalls with fewer than 5 or 6
arguments. of course it's impossible for syscalls to have different
clobbers depending on their number of arguments. the clobberlist for
the recently-added 5- and 6-argument forms was correct, and for the 0-
to 4-argument forms was erroneously copied from the mips o32 ABI where
the additional arguments had to be passed on the stack.

in making this change, I reviewed the kernel sources, and $8 and $9
are always saved for 64-bit kernels since they're part of the syscall
argument list for n32 and n64 ABIs.

use namespace-safe __lseek for __stdio_seek instead of direct syscall

this probably saves a few bytes, avoids duplicating the clunky
lseek/_llseek syscall convention in two places, and sets the stage for
fixing broken seeks on x32 and mipsn32.

release 1.1.23

update year in COPYRIGHT file

update authors/contributors list

these additions were made by scanning git log since the last major
update in commit 1366b3c5e6d89d5ba90dd41fe5bf0246c5299b84.

as before my aim was adding everyone with either substantial code
contributions or a pattern of ongoing simple patch submission; any
omissions are unintentional.

fix build failure on arm building C code in thumb1 mode

a fully thumb1 build is not supported because some asm files are
incompatible with thumb1, but apparently it works to compile the C
code as thumb1

commit 06fbefd10046a0fae7e588b7c6d25fb51811b931 caused this regression
but introducing use of the clz instruction, which is not supported in
arm mode prior to v5, and not supported in thumb prior to thumb2
(v6t2). commit 1b9406b03c0a94ebe2076a8fc1746a8c45e78a83 fixed the
issue only for arm mode pre-v5 but left thumb1 broken.

fix sigaltstack to ignore ss_size with SS_DISABLE, per POSIX

use the correct attributes for ___errno_location

In the public header, __errno_location is declared with the "const"
attribute, conditional on __GNUC__. Ensure that its internal alias has
the same attributes.

Maintainer's note: This change also fixes a regression in quality of
code generation -- multiple references to errno in a single function
started generating multiple calls again -- introduced by commit
e13063aad7aee341d278d2a879a76ec7b59b2ad8.

fix conflicting mips and powerpc definitions for TIOCSER_TEMT macro

Commit 3517d74a5e04a377192d1f4882ad6c8dc22ce69a changed the token in
sys/ioctl.h from 0x01 to 1, so bits/termios.h no longer matches. Revert
the bits/termios.h change to keep the headers in sync.

This reverts commit 9eda4dc69c33852c97c6f69176bf45ffc80b522f.

fix restrict violations in internal use of several functions

The old/new parameters to pthread_sigmask, sigprocmask, and setitimer
are marked restrict, so passing the same address to both is
prohibited. Modify callers of these functions to use a separate object
for each argument.

mention mips64 n32 ABI support in INSTALL doc

document riscv64 support in INSTALL document

prevent dup2 action for posix_spawn internal pipe fd

as reported by Tavian Barnes, a dup2 file action for the internal pipe
fd used by posix_spawn could cause it to remain open after execve and
allow the child to write an artificial error into it, confusing the
parent. POSIX allows internal use of file descriptors by the
implementation, with undefined behavior for poking at them, so this is
not a conformance problem, but it seems preferable to diagnose and
prevent the error when we can do so easily.

catch attempts to apply a dup2 action to the internal pipe fd and
emulate EBADF for it instead.

fix inadvertent use of uninitialized variable in dladdr

commit c8b49b2fbc7faa8bf065220f11963d76c8a2eb93 introduced code that
checked bestsym to determine whether a matching symbol was found, but
bestsym is uninitialized if not. instead use best, consistent with use
in the rest of the function.

simplified from bug report and patch by Cheng Liu.

remove spurious MAP_32BIT definition from riscv64 arch

this was apparently copied from x86_64; it's not part of the kernel
API for riscv64. this change eliminates the need for a
riscv64-specific bits header and lets it use the generic one.

configure: make AR and RANLIB customizable

remove stray .end directives from powerpc[64] asm

maintainer's note: these are not meaningful/correct/needed and the
clang integrated assembler errors out upon seeing them.

add new syscall numbers from linux v5.1

syscall numbers are now synced up across targets (starting from 403 the
numbers are the same on all targets other than an arch specific offset)

IPC syscalls sem*, shm*, msg* got added where they were missing (except
for semop: only semtimedop got added), the new semctl, shmctl, msgctl
imply IPC_64, see

  linux commit 0d6040d4681735dfc47565de288525de405a5c99
  arch: add split IPC system calls where needed

new 64bit time_t syscall variants got added on 32bit targets, see

  linux commit 48166e6ea47d23984f0b481ca199250e1ce0730a
  y2038: add 64-bit time_t syscalls to all 32-bit architectures

new async io syscalls got added, see

  linux commit 2b188cc1bb857a9d4701ae59aa7768b5124e262e
  Add io_uring IO interface

  linux commit edafccee56ff31678a091ddb7219aba9b28bc3cb
  io_uring: add support for pre-mapped user IO buffers

a new syscall got added that uses the fd of /proc/<pid> as a stable
handle for processes: allows sending signals without pid reuse issues,
intended to eventually replace rt_sigqueueinfo, kill, tgkill and
rt_tgsigqueueinfo, see

  linux commit 3eb39f47934f9d5a3027fe00d906a45fe3a15fad
  signal: add pidfd_send_signal() syscall

on some targets (arm, m68k, s390x, sh) some previously missing syscall
numbers got added as well.

ipc: prefer SYS_ipc when it is defined

Linux v5.1 introduced ipc syscalls on targets where previously only
SYS_ipc was available, change the logic such that the ipc code keeps
using SYS_ipc which works backward compatibly on older kernels.

This changes behaviour on microblaze which had both mechanisms, now
SYS_ipc will be used instead of separate syscalls.

mips64: fix syscall numbers of io_pgetevents and rseq

the numbers added in

  commit d149e69c02eb558114f20ea718810e95538a3b2f
  add io_pgetevents and rseq syscall numbers from linux v4.18

were incorrect.

elf.h: add NT_ARM_PAC{A,G}_KEYS from linux v5.1

to request or change pointer auth keys for criu via ptrace, new in

  linux commit d0a060be573bfbf8753a15dca35497db5e968bb0
  arm64: add ptrace regsets for ptrauth key management

netinet/in.h: add INADDR_ALLSNOOPERS_GROUP from linux v5.1

RFC 4286: "The IPv4 multicast address for All-Snoopers is 224.0.0.106."
from

  linux commit 4effd28c1245303dce7fd290c501ac2c11052114
  bridge: join all-snoopers multicast address

sys/socket.h: add SO_BINDTOIFINDEX from linux v5.1

SO_BINDTOIFINDEX behaves similar to SO_BINDTODEVICE, but takes a
network interface index as argument, rather than the network
interface name. see

  linux commit f5dd3d0c9638a9d9a02b5964c4ad636f06cf7e2c
  net: introduce SO_BINDTOIFINDEX sockopt

s390x: drop SO_ definitions from bits/socket.h

the s390x definitions matched the generic ones in sys/socket.h.

netinet/in.h: add IPV6_ROUTER_ALERT_ISOLATE from linux v5.1

restricts router alert packets received by the socket to the
socket's namespace only. see

  linux commit 9036b2fe092a107856edd1a3bad48b83f2b45000
  net: ipv6: add socket option IPV6_ROUTER_ALERT_ISOLATE

sys/prctl.h: add PR_SPEC_DISABLE_NOEXEC from linux v5.1

allows specifying that the speculative store bypass disable bit should
be cleared on exec. see

  linux commit 71368af9027f18fe5d1c6f372cfdff7e4bde8b48
  x86/speculation: Add PR_SPEC_DISABLE_NOEXEC

fcntl.h: add F_SEAL_FUTURE_WRITE from linux v5.1

needed for android so it can migrate from its ashmem to memfd.
allows making the memfd readonly for future users while keeping
a writable mmap of it. see

  linux commit ab3948f58ff841e51feb845720624665ef5b7ef3
  mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd

sys/fanotify.h: update for linux v5.1

includes changes from linux v5.1

  linux commit 235328d1fa4251c6dcb32351219bb553a58838d2
  fanotify: add support for create/attrib/move/delete events

  linux commit 5e469c830fdb5a1ebaa69b375b87f583326fd296
  fanotify: copy event fid info to user

  linux commit e9e0c8903009477b630e37a8b6364b26a00720da
  fanotify: encode file identifier for FAN_REPORT_FID

as well as earlier changes that were missed.

sys/statfs.h is included for fsid_t.

fix deadlock in synccall after threaded fork

synccall may be called by AS-safe functions such as setuid/setgid after
fork. although fork() resets libc.threads_minus_one, causing synccall to
take the single-threaded path, synccall still takes the thread list
lock. This lock may be held by another thread if for example fork()
races with pthread_create(). After fork(), the value of the lock is
meaningless, so clear it.

maintainer's note: commit 8f11e6127fe93093f81a52b15bb1537edc3fc8af and
e4235d70672d9751d7718ddc2b52d0b426430768 introduced this regression.
the state protected by this lock is the linked list, which is entirely
replaced in the child path of fork (next=prev=self), so resetting it
is semantically sound.

cap getdents length argument to INT_MAX

the linux syscall treats this argument as having type int, so passing
extremely long buffer sizes would be misinterpreted by the kernel.
since "short reads" are always acceptable, just cap it down.

patch based on report and suggested change by Florian Weimer.

remove unnecessary and problematic _Noreturn from crt/ldso startup

after commit a48ccc159a5fa061a18419296100ee48a1cd6cc9 removed the use
of _Noreturn on the stage3_func type (which only worked due to it
being defined to the "GNU C" attribute in C99 mode), GCC could no
longer assume that the ends of __dls2 and __dls2b are unreachable, and
produced a warning that a function marked _Noreturn returns.

also, since commit 4390383b32250a941ec616e8bff6f568a801b1c0, the
_Noreturn declaration for __libc_start_main in crt1/rcrt1 has been not
only inconsistent with the definition, but wrong. formally,
__libc_start_main does return, via a (hopefully) tail call to a helper
function after the barrier. incorrect usage of _Noreturn in the
declaration was probably formal UB.

the _Noreturn specifiers were not useful in any of these places, so
remove them all. now, the only remaining usage of _Noreturn is in
public interfaces where _Noreturn is part of their contract.

allow fmemopen with zero size

previously, POSIX erroneously required this to fail with EINVAL
despite the traditional glibc implementation, on which the POSIX
interface was based, allowing it. the resolution of Austin Group issue
818 removes the requirement to fail.

do not use _Noreturn for a function pointer in dynamic linker

_Noreturn is a C11 construct, and may only be used at the site of a
function definition.

remove implicit include of sys/sysmacros.h from sys/types.h

this reverts commit f552c792c7ce5a560f214e1104d93ee5b0833967, which
exposed the sysmacros.h macros (device major/minor calculations) for
BSD and GNU profiles to mimic an unintentional glibc behavior some
code depended on. glibc has deprecated and since removed them as the
resolution to bug #19239, so it makes no sense for us to keep this
behavior. affected code should all have been fixed by now, and if it's
not yet fixed it needs to be for use with modern glibc anyway.

add riscv64 architecture support

Author: Alex Suykov <alex.suykov@gmail.com>
Author: Aric Belsito <lluixhi@gmail.com>
Author: Drew DeVault <sir@cmpwn.com>
Author: Michael Clark <mjc@sifive.com>
Author: Michael Forney <mforney@mforney.org>
Author: Stefan O'Rear <sorear2@gmail.com>

This port has involved the work of many people over several years. I
have tried to ensure that everyone with substantial contributions has
been credited above; if any omissions are found they will be noted
later in an update to the authors/contributors list in the COPYRIGHT
file.

The version committed here comes from the riscv/riscv-musl repo's
commit 3fe7e2c75df78eef42dcdc352a55757729f451e2, with minor changes by
me for issues found during final review:

- a_ll/a_sc atomics are removed (according to the ISA spec, lr/sc
  are not safe to use in separate inline asm fragments)

- a_cas[_p] is fixed to be a memory barrier

- the call from the _start assembly into the C part of crt1/ldso is
  changed to allow for the possibility that the linker does not place
  them nearby each other.

- DTP_OFFSET is defined correctly so that local-dynamic TLS works

- reloc.h LDSO_ARCH logic is simplified and made explicit.

- unused, non-functional crti/n asm files are removed.

- an empty .sdata section is added to crt1 so that the
  __global_pointer reference is resolvable.

- indentation style errors in some asm files are fixed.

optimize aarch64 dynamic tlsdesc function to spill fewer registers

with the glibc generation counter model for reusing dynamic tls slots
after dlclose, it's really not possible to get away with fewer than 4
working registers. for us however it's always been possible, but
tricky, and only became apparent after the switch to installing new
dynamic tls at dlopen time. by merging the negated thread pointer into
the addend early, the register holding the thread pointer can
immediately be reused, bringing the working register count down to
three. this allows saving/restoring via a single stp/ldp pair, since
the return register x0 does not need to be saved.

net reduction of 3 instructions, 2 of which were push/pop.

make powerpc64 vrregset_t logical layout match expected API

between v2 and v3 of the powerpc64 port patch, the change was made
from a 32x4 array of 32-bit unsigned ints for vrregs[] to a 32-element
array of __int128. this mismatches the API applications working with
mcontext_t expect from glibc, and seems to have been motivated by a
misinterpretation of a comment on how aarch64 did things as a
suggestion to do the same on powerpc64.

fix vrregset_t layout and member naming on powerpc64

the mistaken layout seems to have been adapted from 32-bit powerpc,
where vscr and vrsave are packed into the same 128-bit slot in a way
that looks like it relies on non-overlapping-ness of the value bits in
big endian.

the powerpc64 port accounted for the fact that the 64-bit ABI puts
each in its own 128-bit slot, but ordered them incorrectly (matching
the bit order used on the 32-bit ABI), and failed to account for vscr
being padded according to endianness so that it can be accessed via
vector moves.

in addition to ABI layout, our definition used different logical
member layout/naming from glibc, where vscr is a structure to
facilitate access as a 32-bit word or a 128-bit vector. the
inconsistency here was unintentional, so fix it.

fix tls offsets when p_vaddr%p_align != 0 on TLS_ABOVE_TP targets

currently the bfd linker does not seem to create tls segments where
p_vaddr%p_align != 0, but this is valid in ELF and then the runtime
computed tls offset must satisfy

  offset%p_align == (base+p_vaddr)%p_align

and in case of local exec tls (main executable) the smallest such
offset must be used (otherwise it is incompatible with the offset
computed by the static linker). the !TLS_ABOVE_TP case is handled
correctly (the offset is negative then in the formula).

the ldso code for TLS_ABOVE_TP is changed so the static tls offset
of each module satisfies the formula.

fix static tls offsets of shared libs on TLS_ABOVE_TP targets

tls_offset should always point to the end of the allocated static tls
area, but this was not handled correctly on "tls variant 1" targets
in the dynamic linker:

after application tls was allocated, tls_offset was aligned up,
potentially wasting tls space. (alignment may be needed at the
begining of the tls area, not at the end, but that will be fixed
separately as it is unlikely to affect real binaries.)

when static tls was allocated for a shared library, tls_offset was
only updated with the size of the tls segment which does not include
alignment gaps, which can easily happen if the tls size update for
one library leaves tls_offset misaligned for the next one. this can
cause oob access in __copy_tls or arbitrary breakage at tls access.
(the issue was observed on aarch64 with rust binaries)

fix format strings for uid/gid values in putpwent/putgrent

commit 648c3b4e18b2ce2b6af7d44783e42ca267ea49f5 omitted this change,
which is needed to be able to use uid/gid values greater than INT_MAX
with these interfaces. it fixes alpine linux bug #10460.

remove unused struct dso members from dynlink.c

maintainer's note: commit 9d44b6460ab603487dab4d916342d9ba4467e6b9
removed their use.