add further ioctl time64 fallback conversions

this commit covers all remaining ioctls I'm aware of that use
time_t-derived types in their interfaces. it may still be incomplete,
and has undergone only minimal testing for a few commands used in
audio playback.

the SNDRV_PCM_IOCTL_SYNC_PTR command is special-cased because, rather
than the whole structure expanding, it has two substructures each
padded to 64 bytes that expand within their own 64-byte reserved zone.
as long as it's the only one of its type, it doesn't really make sense
to make a general framework for it, but the existing table framework
is still used for the substructures in the special-case. one of the
substructures, snd_pcm_mmap_status, has a snd_pcm_uframes_t member
which is not a timestamp but is expanded just like one, to match the
64-bit-arch version of the structure. this is handled just like a
timestamp at offset 8, and is the motivation for the conversions table
holding offsets of individual values to be expanded rather than
timespec/timeval type pairs.

for some of the types, the size to which they expand is dependent on
whether the arch's ABI aligns 8-byte types on 8-byte boundaries.
new_req entries in the table need to reflect this size to get the
right ioctl request number that will match what callers pass, but we
don't have access to the actual structure type definitions here and
duplicating them would be cumbersome. instead, the new_misaligned
macro introduced here constructs an artificial object whose size is
the result of expanding a misaligned timespec/timeval to 64-bit and
imposing the arch's alignment on the result, which can be passed to
the _IO{R,W,WR} macros.

improve ioctl time64 conversion fallback framework

record offsets of individual slots that expand from 32- to 64-bit,
rather than timespec/timeval pairs. this flexibility will be needed
for some ioctls. reduce size of types in table. adjust representation
of offsets to include a count rather than needing -1 padding so that
the table is less ugly and doesn't need large diffs if we increase max
number of slots.

convert ioctl time64 fallbacks to table-driven framework

with the current set of supported ioctls, this conversion is hardly an
improvement, but it sets the stage for being able to do alsa, v4l2,
ppp, and other ioctls with timespec/timeval-derived types. without
this capability, a lot of functionality users depend on would stop
working with the time64 switchover.

fix regression in ioctl definitions provided by arch/generic bits

commit b60fdf133c033d4ad6b04a8237f253563fae5928 broke the
SIOCGSTAMP[NS] ioctl fallbacks introduced in commit
2e554617e5a6a41bf3f6c6306c753cd53abf728c, as well as use of these
ioctls, by creating a situation where bits/ioctl.h could be included
without __LONG_MAX being visible.

hook recvmmsg up to SO_TIMESTAMP[NS] fallback for pre-time64 kernels

always try the time64 syscall first since we can use its success to
conclude that no conversion is needed (any setsockopt for the
timestamp options would have succeeded without need for fallbacks).
otherwise, we have to remember the original controllen for each
msghdr, requiring O(vlen) space, so vlen must be bounded. linux clamps
it to IOV_MAX for sendmmsg only (not recvmmsg), but doing the same for
recvmmsg is not unreasonable, especially since the limitation will
only apply to old kernels.

we could optimize to avoid trying SYS_recvmmsg_time64 first if all
msghdrs have controllen zero, or support unlimited vlen by looping and
emulating the timeout logic, but I'm not inclined to do complex and
error-prone optimizations on a function that has so many underlying
problems it should really never be used.

implement SO_TIMESTAMP[NS] fallback for kernels without time64 versions

the definitions of SO_TIMESTAMP* changed on 32-bit archs in commit
38143339646a4ccce8afe298c34467767c899f51 to the new versions that
provide 64-bit versions of timeval/timespec structure in control
message payload. socket options, being state attached to the socket
rather than function calls, are not trivial to implement as fallbacks
on ENOSYS, and support for them was initially omitted on the
assumption that the ioctl-based polling alternatives (SIOCGSTAMP*)
could be used instead by applications if setsockopt fails.

unfortunately, it turns out that SO_TIMESTAMP is sufficiently old and
widely supported that a number of applications assume it's available
and treat errors as fatal.

this patch introduces emulation of SO_TIMESTAMP[NS] on pre-time64
kernels by falling back to setting the "_OLD" (time32) versions of the
options if the time64 ones are not recognized, and performing
translation of the SCM_TIMESTAMP[NS] control messages in recvmsg.
since recvmsg does not know whether its caller is legacy time32 code
or time64, it performs translation for any SCM_TIMESTAMP[NS]_OLD
control messages it sees, leaving the original time32 timestamp as-is
(it can't be rewritten in-place anyway, and memmove would be mildly
expensive) and appending the converted time64 control message at the
end of the buffer. legacy time32 callers will see the converted one as
a spurious control message of unknown type; time64 callers running on
pre-time64 kernels will see the original one as a spurious control
message of unknown type. a time64 caller running on a kernel with
native time64 support will only see the time64 version of the control
message.

emulation of SO_TIMESTAMPING is not included at this time since (1)
applications which use it seem to be prepared for the possibility that
it's not present or working, and (2) it can also be used in sendmsg
control messages, in a manner that looks complex to emulate
completely, and costly even when running on a time64-supporting
kernel.

corresponding changes in recvmmsg are not made at this time; they will
be done separately.

signal to kernel headers that time_t is 64-bit

linux/input.h and perhaps others use this macro to determine whether
the userspace time_t is 64-bit when potentially defining types in
terms of time_t and derived structures. the name __USE_TIME_BITS64 is
unfortunate; it really should have been in the __UAPI namespace. but
this is what was chosen back in v4.16 when first preparing input.h for
time64 userspace, presumably based on expectations about what the
glibc-internal features.h macro for time64 would be, and changing it
now would just put a new minimum version requirement on kernel
headers.

the __USE_TIME_BITS64 macro is not intended as a public interface. it
is purely an internal contract between libc and Linux uapi headers.

fix null pointer dereference in setitimer time32 compat shim

this interface permits a null pointer for where to store the old
itimerval being replaced. an early version of the time32 compat shim
code had corresponding bugs for lots of functions; apparently
setitimer was overlooked when fixing them.

arm: avoid conditional branch to PLT in sigsetjmp

The R_ARM_THM_JUMP19 relocation type generated for the original code
when targeting Thumb 2 is not supported by the gold linker.

riscv64: fix fesetenv(FE_DFL_ENV) crash

When FE_DFL_ENV is passed to fesetenv(), the very first instruction
lw t1, 0(a0) will fail since a0 is -1.

update contributor name

This changes my name in the COPYRIGHT file, and adds a .mailmap entry
for my new name.

ppc: add configure check for older compilers erroring on 'd' constraint

fix build regression on mips64 due to endian.h removal

commit 4d3a162d001a93edd285fb6603a883c30ae553ba overlooked that the
mips64 reloc.h dependent on endian.h not only for setting the ABI ldso
name to match the byte order, but also for use of the byte swapping
macros. they are needed to override R_TYPE, R_SYM, and R_INFO, to
compensate for a mips "quirk" of always using big endian order for
symbol references in relocations.

part of that commit canot be reverted because the original code was
wrong: it's invalid to define _GNU_SOURCE or any feature test macro
in reloc.h, or anywhere except at the top of a source file. however,
thanks to commit 316730cdc7a330cddf288b4e5c1de5daa64e19f4, the feature
test macro is no longer needed to access the endian-swapping macros,
so simply bringing back the #include directive suffices.

fix failure to build time32 compat shims with out-of-tree builds

commit de90f38e3b105802655d19d965d66335d25d59ef omitted $(srcdir) from
the makefile include pathname it added. since the include directive
was prefixed with - to make it optional (for archs that don't use it),
the failure to find arch/$(ARCH)/arch.mak was silent.

fix time64 link regression of dlsym stub for static-linked programs

in commit 22daaea39f1cc5f7391f0a5cd84576ffb58c2860, the
__dlsym_redir_time64 function providing the backend for __dlsym_time64
was defined only in the dynamic linker, and thus was undefined when
static linking a program referencing dlsym. use the same stub_dlsym
definition that provides __dlsym (the non-redirecting backend) for
static linked programs to provide it, conditional on _REDIR_TIME64.

move time_t and suseconds_t definitions to common alltypes.h.in

now that all 32-bit archs have 64-bit time_t (and suseconds_t), the
arch-provided _Int64 macro (long or long long, as appropriate) can be
used to define them, and arch-specific definitions are no longer
needed.

move time64 ioctl numbers to generic bits/ioctl.h

now that all 32-bit archs have 64-bit time types, the values for the
time-related ioctls can be shared. the mechanism for this is an
arch/generic version of the bits header. archs which don't use the
generic header still need to duplicate the definitions.

x32, which does not use the new time64 values of the macros, already
has its own overrides, so this commit does not affect it.

move time64 socket options from arch bits to top-level sys/socket.h

now that all 32-bit archs have 64-bit time types, the values for the
time-related socket option macros can be treated as universal for
32-bit archs. the sys/socket.h mechanism for this predates
arch/generic and is instead in the top-level header.

x32, which does not use the new time64 values of the macros, already
has its own overrides, so this commit does not affect it.

switch all existing 32-bit archs to 64-bit time_t

this commit preserves ABI fully for existing interface boundaries
between libc and libc consumers (applications or libraries), by
retaining existing symbol names for the legacy 32-bit interfaces and
redirecting sources compiled against the new headers to alternate
symbol names. this does not necessarily, however, preserve the
pairwise ABI of libc consumers with one another; where they use
time_t-derived types in their interfaces with one another, it may be
necessary to synchronize updates with each other.

the intent is that ABI resulting from this commit already be stable
and permanent, but it will not be officially so until a release is
made. changes to some header-defined types that do not play any role
in the ABI between libc and its consumers may still be subject to
change.

mechanically, the changes made by this commit for each 32-bit arch are
as follows:

- _REDIR_TIME64 is defined to activate the symbol redirections in
  public headers

- COMPAT_SRC_DIRS is defined in arch.mak to activate build of ABI
  compat shims to serve as definitions for the original symbol names

- time_t and suseconds_t definitions are changed to long long (64-bit)

- IPC_STAT definition is changed to add the IPC_TIME64 bit (0x100),
  triggering conversion of semid_ds, shmid_ds, and msqid_ds split
  low/high time bits into new time_t members

- structs semid_ds, shmid_ds, msqid_ds, and stat are modified to add
  new 64-bit time_t/timespec members at the end, maintaining existing
  layout of other members.

- socket options (SO_*) and ioctl (sockios) command macros are
  redefined to use the kernel's "_NEW" values.

in addition, on archs where vdso clock_gettime is used, the
VDSO_CGT_SYM macro definition in syscall_arch.h is changed to use a
new time64 vdso function if available, and a new VDSO_CGT32_SYM macro
is added for use as fallback on kernels lacking time64.

add x32 bits/ioctl_fix.h defining time-related sockios macros

these definitions are copied from generic bits/ioctl.h, so that x32
keeps the "_OLD" versions (which are already time64 on x32) when
32-bit archs switch to 64-bit time_t.

add back x32 bits/socket.h defining time-related socket options

these definitions are merely copied from the top-level sys/socket.h,
so there is no functional change at this time. however, the top-level
definitions will change to use the time64 "_NEW" versions on 32-bit
archs when time_t is switched over to 64-bit. this commit ensures that
change will be suppressed on x32.

move msghdr and cmsghdr out of bits/socket.h

these structures can now be defined generically in terms of endianness
and long size. previously, the 32-bit archs all shared a common
definition from the generic bits header, and each 64-bit arch had to
repeat the 64-bit version, with endian conditionals if the arch had
variants of each endianness.

I would prefer getting rid of the preprocessor conditionals for
padding and instead using unnamed bitfield members, like commit
9b2921bea1d5017832e1b45d1fd64220047a9802 did for struct timespec.
however, at present sendmsg, recvmsg, and recvmmsg need access to the
padding members by name to zero them. this could perhaps be cleaned up
in the future.

fix x32 msghdr struct by removing x32 bits/socket.h

being that it contains pointers and (from the kernel perspective,
which is wrong) size_t members, x32 uses the 32-bit version of the
structure, not a half-32-bit, half-64-bit layout like we had here. the
x86_64 definition was inadvertently copied when x32 was first added.

unlike errors in the opposite direction (missing padding), this error
was not easily detected breakage, because the layout of the commonly
used initial subset of members still matched. breakage could only be
observed in the presence of control messages or flags.

make time-related socket options overridable by arch bits files

SO_RCVTIMEO and SO_SNDTIMEO already were, but only in aggregate with
SO_DEBUG and all of the other low/traditional options that varied per
arch. SO_TIMESTAMP* are newly overridable. the two groups have to be
done separately since mips64 and powerpc64 will override the former
but not the latter.

at some point this should be cleaned up to use bits headers more
idiomatically.

add framework for arch-provided makefile fragments, compat source dirs

the immediate usage case for this is to let 32-bit archs moving to
64-bit time_t via symbol redirection pull in wrapper shims that
provide the old symbol names. in the future it may be used for other
types of compatibility-only source files that are not relevant to all
archs.

add __dlsym_time64 asm entry point for all legacy-32bit-time_t archs

add time64 redirect for, and redirecting implementation of, dlsym

if symbols are being redirected to provide the new time64 ABI, dlsym
must perform matching redirections; otherwise, it would poke a hole in
the magic and return pointers to functions that are not safe to call
from a caller using time64 types.

rather than duplicating a table of redirections, use the time64
symbols present in libc's symbol table to derive the decision for
whether a particular symbol needs to be redirected.

add time32 ABI compat shims, compat source tree

these files provide the symbols for the traditional 32-bit time_t ABI
on existing 32-bit archs by wrapping the real, internal versions of
the corresponding functions, which always work with 64-bit time_t.
they are written to be as agnostic as possible to the implementation
details of the real functions, so that they can be written once and
mostly forgotten, but they are aware of details of the old (and
sometimes new) ABI, which is okay since ABI is fixed and cannot
change.

a new compat tree is added, separate from src, which the Makefile does
not see or use now, but which archs will be able to add to the build
process. we could also consider moving other things that are compat
shims here, like functions which are purely for glibc-ABI-compat, with
the goal of making it optional or just cleaning up the main src tree
to make the distinction between actual implementation/API files and
ABI-compat shims clear.

make fstatat fill in old time32 stat fields too

here _REDIR_TIME64 is used as an indication that there's an old ABI,
and thereby the old time32 timespec fields of struct stat.

keeping struct stat compatible and providing both versions of the
timespec fields is done so that ftw/nftw does not need painful compat
shims, and (more importantly) so that similar interfaces between pairs
of libc consumers (applications/libraries) will be less likely to
break when one has been rebuilt for time64 but the other has not.

disable lfs64 aliases for remapped time64 functions

these functions cannot provide the glibc lfs64-ABI-compatible symbols
when time_t differs from what it was in that ABI. instead, the aliases
need to be provided by the time32 compat shims or through some other
mechanism.

prepare struct sched_param for change in time_t definition

the time_t members in struct sched_param are just reserved space to
preserve size and alignment. when time_t changes to 64-bit on 32-bit
archs, this structure should not change.

make definition conditional on _REDIR_TIME64 to match the size of the
old time_t, which can be assumed to be long if _REDIR_TIME64 is
defined.

add time64 symbol name redirects to public headers, under arch control

a _REDIR_TIME64 macro is introduced, which the arch's alltypes.h is
expected to define, to control redirection of symbol names for
interfaces that involve time_t and derived types. this ensures that
object files will only be linked to libc interfaces matching the ABI
whose headers they were compiled against.

along with time32 compat shims, which will be introduced separately,
the redirection also makes it possible for a single libc (static or
shared) to be used with object files produced with either the old
(32-bit time_t) headers or the new ones after 64-bit time_t switchover
takes place. mixing of such object files (or shared libraries) in the
same program will also be possible, but must be done with care; ABI
between libc and a consumer of the libc interfaces is guaranteed to
match by the the symbol name redirection, but pairwise ABI between
consumers of libc that define interfaces between each other in terms
of time_t is not guaranteed to match.

this change adds a dependency on an additional "GNU C" feature to the
public headers for existing 32-bit archs, which is generally
undesirable; however, the feature is one which glibc has depended on
for a long time, and thus which any viable alternative compiler is
going to need to provide. 64-bit archs are not affected, nor will
future 32-bit archs be, regardless of whether they are "new" on the
kernel side (e.g. riscv32) or just newly-added (e.g. a new sparc or
xtensa port). the same applies to newly-added ABIs for existing
machine-level archs.

add missing m68k user.h/procfs.h regset types

update case mappings to unicode 12.1.0

update ctype data to unicode 12.1.0

overhaul wide character case mapping implementation

the existing implementation of case mappings was very small (typically
around 1.5k), but unmaintainable, requiring manual addition of new
case mappings with each new edition of Unicode. often, it turned out
that newly-added case mappings were not easily representable in the
existing tightly-constrained table structures, requiring new hacks to
be invented and delaying support for new characters.

the new implementation added here follows the pattern used for
character class membership, with a two-level table allowing Unicode
blocks for which no data is needed to be elided. however, rather than
single-bit data, each character maps to a one of up to 6 case-mapping
rules available to its block, where 6 is floor(cbrt(256)) and allow 3
characters to be represented per byte (vs 8 with bit tables). blocks
that would need more than 6 rules designate one as an exception and
let lookup pass into a binary search of exceptional cases for the
block.

the number 6 was chosen empirically; many blocks would be ok with 4
rules (uncased, lower, upper, possible exceptions), some even just
with 2, but the latter are rare and fitting 4 characters per byte
rather than 3 does not save significant space. moreover, somewhat
surprisingly, there are sufficiently many blocks where even 4 rules
don't suffice without a lot of exceptions (blocks where some case
pairs are laced, others offset) that originally I was looking at
supporting variable-width tables, with 1-, 2-, or 3-bit entries,
thereby allowing blocks with 8 rules. as implemented in my
experiments, that version was significantly larger and involved more
memory accesses/cache lines.

improvements in size at the expense of some performance might be
possible by utilizing iswalpha data or merging the table of case
mapping identity with alphabetic identity. these were explored
somewhat when the code was first written, and might be worth
revisiting in the future.

add missing case mapping between U+03F3 and U+037F

somehow this seems to have been overlooked. add it now so that
subsequent overhaul of case mapping implementation will not introduce
a functional change at the same time.

fix errno for posix_openpt with no free ptys available

linux fails the open with ENOSPC, but POSIX mandates EAGAIN.

adjust struct timespec definition to be time64-ready

for time64 support on 32-bit archs, the kernel interfaces use a
timespec layout padded to match the representation of a pair of 64-bit
values, which requires endian-specific padding.

use of an ordinary, non-bitfield, named member for the padding is
undesirable because, on big endian archs, it would alter the
interpretation of traditional (non-designated) initializers of the
form {s,ns}, initializing the padding instead of the tv_nsec member.
unnamed bitfield members solve this problem by not taking part in
initialization, and were the expected solution when the kernel
interfaces were designed. however, they also have further advantages
which we take advantage of here:

positioning of the padding could be controlled by having a
preprocessor conditional with separate definitions of struct timespec
for little and big endian, but whether padding should appear at all is
a function of whether time_t is larger than long. this condition is
not something the preprocessor can determine unless we were to define
a new macro specifically for that purpose.

by using unnamed bitfield members instead of ordinary named members,
we can arrange for the size of the padding to collapse to zero when it
should not be present, just by using sizeof(time_t) and sizeof(long)
in the bitfield width expression, which can be any integer constant
expression.

clock_adjtime: generalize time64 not to assume old struct layout match

commit 2b4fd6f75b4fa66d28cddcf165ad48e8fda486d1 added time64 for this
function, but did so with a hidden assumption that the new time64
version of struct timex will be layout-compatible with the old one.
however, there is little benefit to doing it that way, and the cost is
permanent special-casing of 32-bit archs with 64-bit time_t in the
public interface definitions.

instead, do a full translation of the structure going in and out. this
commit is actually a revision to an earlier uncommited version of the
code.

wait4, getrusage: add time64/x32 variant

presently the kernel does not actually define time64 versions of these
syscalls, and they're not really needed except to represent extreme
cpu time usage. however, x32's versions of the syscalls already behave
as time64 ones, meaning the functions were broken on x32 if the caller
used any part of the rusage result other than ru_utime and ru_stime.
commit 7e8171143124f7f510db555dc6f6327a965a3e84 made it possible to
fix this by treating x32's syscalls as time64 versions.

in the non-time64-syscall case, make the syscall with the rusage
destination pointer adjusted so that all members but the timevals line
up between the libc and kernel structures. on 64-bit archs, or present
32-bit archs with 32-bit time_t, the timevals will line up too and no
further work is needed. for future 32-bit archs with 64-bit time_t,
the timevals are copied into place, contingent on time_t being larger
than long.

internally, define time64 rusage syscalls on x32 as the existing ones

this is analogous to commit 40aa18d55ab763e69ad16d0cf1cebea708ffde47.
so far, there are not any actual time64 versions of the rusage
syscalls (getrusage and wait4) and might never be. however, the
existing x32 ones behave the way time64 versions would if they
existed: using 64-bit slots in place of all longs.

presently, wait4 and getrusage are broken on x32, storing the timevals
correctly but messing up everything else due to the long/kernel-long
mismatch. this would be a huge buffer overflow if not for the 16
reserved slots we left long ago, which suffice to prevent 14
double-sized longs from overflowing into unrelated memory. this commit
will make it possible to fix them.

use struct pt_regs * rather than void * for powerpc[64] sigcontext regs

this is to match the kernel and glibc interfaces. here, struct pt_regs
is an incomplete type, but that's harmless, and if it's completed by
inclusion of another header then members of the struct pointed to by
the regs member can be accessed directly without going through a cast
or intermediate pointer object.

fix fpregset_t type on powerpc64

the userspace ucontext API has this as an array rather than a
structure.

commit 3c59a868956636bc8adafb1b168d090897692532 fixed the
corresponding mistake for vrregset_t, namely that the original
powerpc64 port used a mix of types from 32-bit powerpc and powerpc64
rather than matching the 64-bit types.

fix return value of ungetc when argument is outside unsigned char range

aside from the special value EOF, ungetc is specified to accept and
convert values outside the range of unsigned char. conversion takes
place automatically as part of assignment when storing into the
buffer, but the return value is also required to be the resulting
converted value, and this requirement was not satisfied.

simplified from patch by Wang Jianjian.

fix incorrect use of fabs on long double operand in floatscan.c

based on patch by Dan Gohman, who caught this via compiler warnings.
analysis by Szabolcs Nagy determined that it's a bug, whereby errno
can be set incorrectly for values where the coercion from long double
to double causes rounding. it seems likely that floating point status
flags may be set incorrectly as a result too.

at the same time, clean up use of preprocessor concatenation involving
LDBL_MANT_DIG, which spuriously depends on it being a single unadorned
decimal integer literal, and instead use the equivalent formulation
2/LDBL_EPSILON. an equivalent change on the printf side was made in
commit bff6095d915f3e41206e47ea2a570ecb937ef926.

move pthread types out of per-arch alltypes.h

policy has long been that these definitions are purely a function of
whether long/pointer is 32- or 64-bit, and that they are not allowed
to vary per-arch. move the definition to the shared alltypes.h.in
fragment, using integer constant expressions in terms of sizeof to
vary the array dimensions appropriately. I'm not sure whether this is
more or less ugly than using preprocessor conditionals and two sets of
definitions here, but either way is a lot less ugly than repeating the
same thing for every arch.

define LONG_MAX via arch alltypes.h, strip down bits/limits.h

LLONG_MAX is uniform for all archs we support and plenty of header and
code level logic assumes it is, so it does not make sense for limits.h
bits mechanism to pretend it's variable.

LONG_BIT can be defined in terms of LONG_MAX; there's no reason to put
it in bits.

by moving LONG_MAX definition to __LONG_MAX in alltypes.h and moving
LLONG_MAX out of bits, there are now no plain-C limits that are
defined in the bits header, so the bits header only needs to be
included in the POSIX or extended profiles. this allows the feature
test macro logic to be removed from the bits header, facilitating a
long-term goal of getting such logic out of bits.

having __LONG_MAX in alltypes.h will allow further generalization of
headers.

archs without a constant PAGESIZE no longer need bits/limits.h at all.

make endian.h expose unprefixed macros, functions in standard profile

the resolution of Austin Group issue #162 adds endian.h as a standard
header for future versions of the standard, making it no longer
acceptable for some of the functionality to be hidden behind
_BSD_SOURCE or _GNU_SOURCE. the definitions of the [lb]etoh{16,32,64}
function-like macros are kept conditional since they are alternate
names which the standard did not adopt.

remove use of endian.h from arch reloc.h headers, clean up

building on commit 97d35a552ec5b6ddf7923dd2f9a8eb973526acea,
__BYTE_ORDER is now available wherever alltypes.h is included. since
reloc.h is only used from src/internal/dynlink.h, it can be assumed
that __BYTE_ORDER is exposed. reloc.h is not permitted to be included
in other contexts, and generally, like most arch headers, lacks
inclusion guards that would allow such usage. the mips64 version
mistakenly included such guards; they are removed for consistency.

remove indirect use of endian.h from public headers

building on commit 97d35a552ec5b6ddf7923dd2f9a8eb973526acea,
__BYTE_ORDER is now available wherever alltypes.h is included.
endian.h should not be used since, in the future, it will expose
identifiers that are not in the reserved namespace for the headers
which were previously using it.

move __BYTE_ORDER definition to alltypes.h

this change is motivated by the intersection of several factors.
presently, despite being a nonstandard header, endian.h is exposing
the unprefixed byte order macros and functions only if _BSD_SOURCE or
_GNU_SOURCE is defined. this is to accommodate use of endian.h from
other headers, including bits headers, which need to define structure
layout in terms of endianness. with time64 switch-over, even more
headers will need to do this.

at the same time, the resolution of Austin Group issue 162 makes
endian.h a standard header for POSIX-future, requiring that it expose
the unprefixed macros and the functions even in standards-conforming
profiles. changes to meet this new requirement would break existing
internal usage of endian.h by causing it to violate namespace where
it's used.

instead, have the arch's alltypes.h define __BYTE_ORDER, either as a
fixed constant or depending on the right arch-specific predefined
macros for determining endianness. explicit literals 1234 and 4321 are
used instead of __LITTLE_ENDIAN and __BIG_ENDIAN so that there's no
danger of getting the wrong result if a macro is undefined and
implicitly evaluates to 0 at the preprocessor level.

the powerpc (32-bit) bits/endian.h being removed had logic for varying
endianness, but our powerpc arch has never supported that and has
always been big-endian-only. this logic is not carried over to the new
__BYTE_ORDER definition in alltypes.h.

remove per-arch definitions for va_list

now that commit f7f1079796abc6f97c69521d2334e9c7d3945dd8 removed the
legacy i386 conditional definition, va_list is in no way
arch-specific, and has no reason to be in the future. move it to the
shared part of alltypes.h.in

remove i386 support for legacy struct __va_list

commit ffaaa6d230512f3a7f3d040b943517728f3dc3cf removed the
corresponding stdarg.h support for compilers without va_list builtins,
but failed to remove the alternate type definition, leaving incorrect
va_list definitions in place with compilers that don't define __GNUC__
with a value >= 3.

mips: add single-instruction math functions

SQRT.fmt exists on MIPS II+ (float), MIPS III+ (double).

ABS.fmt exists on MIPS I+ but only cores with ABS2008 flag in FCSR
implement the required behaviour.

fix cacosh results for arguments with negative imaginary part

release 1.1.24

math: fix signed int left shift ub in sqrt

Both sqrt and sqrtf shifted the signed exponent as signed int to adjust
the bit representation of the result. There are signed right shifts too
in the code but those are implementation defined and are expected to
compile to arithmetic shift on supported compilers and targets.

fix aliasing-based undefined behavior in mbsrtowcs

mbsrtowcs contains "vectorized" loops to quickly step over bytes
without the high bit set; these have undefined behavior by virtue of
aliasing uint32_t over top of char data for the accesses.

commit 4d0a82170a25464c39522d7190b9fe302045ddb2 fixed the
corresponding usage in string functions by using the may_alias
attribute conditional on __GNUC__ and disabled the vectorized code in
its absence. do the same for mbsrtowcs.

add Arm to the copyright file

Several math functions are now from the ARM optimized-routines repo
licensed under standard MIT terms and copyrighted by Arm Limited,
so mention this in the COPYRIGHT too.

reintroduce riscv64 struct sigcontext

commit ab3eb89a8b83353cdaab12ed017a67a7730f90e9 removed it as part of
correcting the mcontext_t definition, but there is still code using
struct sigcontext and expecting the member names present in it, most
notably libgcc_eh. almost all such usage is incorrect, but bring back
struct sigcontext at least for now so as not to introduce regressions.

fix riscv64 elf_fpregset_t type and member names mismatch

in order for sys/procfs.h (provided by sys/user.h) to be useful, it
needs to match the API its consumers (gdb, etc.) expect, including the
member names established by glibc.

this partly reverts commit 29e8737f81ccc9fbadcf61a75318aa3d0516aafa,
which partly reverted d493206de7df4db07ad34f24701539ba0a6ed38c,
eliminating struct user_fpregs_struct which seems to have had no
precedent and using union __riscv_mc_fp_state for elf_fpregset_t. this
requires indirect inclusion of signal.h to make union
__riscv_mc_fp_state visible, but being that these are nonstandard
"junk" headers with no official restrictions on what they can pull in,
that's no big deal.

split off and expanded from patch by Khem Raj.

fix riscv64 signal.h namespace violations and ucontext API mismatches

the top-level mcontext_t member names were namespace-violating in
standards profiles before, and nested-level member names (some of them
single-letter) were egregiously bad namespace impositions even in
non-strict profiles. moreover, they mismatched those used in the
public API first defined in glibc, breaking any code making use of
them.

unlike most archs, the public API used in glibc for riscv mcontext_t
members was designed to be namespace-safe, so we can and should expose
the members regardless of feature test macros. only the typedefs for
greg_t, gregset_t, and fpregset_t need to be protected behind FTMs.

the struct tags for mcontext_t and ucontext_t are also changed. for
mcontext_t this is necessary to make the common definition across
profiles namespace-safe. for ucontext_t, it's just a matter of
matching the tag from the glibc-defined API.

these changes are split off and expanded from a patch by Khem Raj.

remove remaining traces of __tls_get_new

Some declarations of __tls_get_new were left in the code, even
though the definition got removed in

  commit 9d44b6460ab603487dab4d916342d9ba4467e6b9
  install dynamic tls synchronously at dlopen, streamline access

this can make the build fail with

  ld: lib/libc.so: hidden symbol `__tls_get_new' isn't defined

when libc.so is linked without --gc-sections, because a .hidden
declaration in asm code creates a reference even if the symbol
is not actually used.

math: optimize lrint on 32bit targets

lrint in (LONG_MAX, 1/DBL_EPSILON) and in (-1/DBL_EPSILON, LONG_MIN)
is not trivial: rounding to int may be inexact, but the conversion to
int may overflow and then the inexact flag must not be raised. (the
overflow threshold is rounding mode dependent).

this matters on 32bit targets (without single instruction lrint or
rint), so the common case (when there is no overflow) is optimized by
inlining the lrint logic, otherwise the old code is kept as a fallback.

on my laptop an i486 lrint call is asm:10ns, old c:30ns, new c:21ns
on a smaller arm core: old c:71ns, new c:34ns
on a bigger arm core: old c:27ns, new c:19ns

clean up mips (32-bit, o32) syscall asm constraints

analogous to commit ddc7c4f936c7a90781072f10dbaa122007e939d0 for
mips64 and n32, remove the hack to load the syscall number into $2 via
asm, and use a constraint to let the compiler load it instead.

now, only $4, $5, and $6 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.

as before, $8, $9, and $10 are conditionally input-output registers
for 5-, 6-, and 7-argument syscalls. their role in input is carrying
in the values that will be stored on the stack for arguments 5-7.
their role in output is carrying back whatever the kernel has
clobbered them with, so that the compiler cannot assume they still
contain the input values.

document mips r6 in INSTALL file

fix mips setjmp/longjmp fpu state on r6, related issues

mips32 has two fpu register file variants: FR=0 with 32 32-bit
registers, where pairs of neighboring even/odd registers are used to
represent doubles, and FR=1 with 32 64-bit registers, each of which
can store a single or double.

up through r5 (our "mips" arch), the supported ABI uses FR=0, but
modern compilers generate "fpxx" model code that can safely operate
with either model. r6, which is an incompatible but similar ISA, drops
FR=0 and only provides the FR=1 model. as such, setjmp and longjmp,
which depended on being able to save and restore call-saved doubles by
storing and loading their 32-bit halves, were completely broken in the
presence of floating point code on mips r6.

to fix this, use the s.d and l.d mnemonics to store and load fpu
registers. these expand to the existing swc1 and lwc1 instructions for
pairs of 32-bit fpu registers on mips1, but on mips2 and later they
translate directly to the 64-bit sdc1 and ldc1.

with FR=0, sdc1 and ldc1 behave just like the pairs of swc1 and lwc1
instructions they replace, storing or loading the even/odd pair of fpu
registers that can be treated as separate single-precision floats or
as a unit representing a double. but with FR=1, they store/load
individual 64-bit registers. this yields the ABI-correct behavior on
mips r6, and should make linking of pre-r6 (plain "mips") code with
"fp64" model code workable, although this is and will likely remain
unsupported usage.

in addition to the mips r6 problem this change fixes, reportedly
clang's internal assembler refuses to assemble swc1 and lwc1
instructions for odd register indices when building for "fpxx" model
(the default). this caused setjmp and longjmp not to build. by using
the s.d and l.d forms, this problem is avoided too.

as a bonus, code size is reduced everywhere but mips1.

fix mips r6 syscall clobber lists not to include hi/lo registers

mips r6 (an incompatible isa from traditional mips) removes the hi and
lo registers used for mul/div results. older gcc versions accepted
them in the clobber list for asm, but their presence is incorrect and
breaks on later versions.

in the process of fixing this, the clobber list for 32-bit mips
syscalls has been deduplicated via a macro like on mips64 and n32.

arm: fix setjmp and longjmp asm for armv8-a

armv8 removed the coprocessor instructions other than cp14, so
on an armv8 system the related hwcaps should never be set.

new llvm complains about the use of coprocessor instructions in
armv8-a mode (even though they are never executed at runtime),
so ifdef them out when musl is built for armv8.

fix data race in timer_create with SIGEV_THREAD notification

in the timer thread start function, self->timer_id was accessed
without synchronization; the timer thread could fail to see the store
from the calling thread, resulting in timer_delete failing to delete
the correct kernel-level timer.

this fix is based on a patch by changdiankang, but with the load moved
to after receiving the timer_delete signal rather than just after the
start barrier, so as not to retain the possibility of data race with
timer_delete.

correct the operand specifiers in the riscv64 CAS routines

The operand sepcifiers in a_cas and a_cas_p for riscv64 were incorrect:
there's a backwards branch in the routine, so despite tmp being written
at the end of the assembly fragment it cannot be allocated in one of the
input registers because the input values may be needed for another trip
around the loop.

For code that follows the guaranteed forward progress requirements, the
backwards branch is rarely taken: SiFive's hardware only fails a store
conditional on execptional cases (ie, instruction cache misses inside
the loop), and until recently a bug in QEMU allowed back-to-back
store conditionals to succeed.  The bug has been fixed in the latest
QEMU release, but it turns out that the fix caused this latent bug in
musl to manifest.

harden thread start with failed scheduling against broken __clone

commit 8a544ee3a2a75af278145b09531177cab4939b41 introduced a
dependency of the failure path for explicit scheduling at thread
creation on __clone's handling of the start function returning, which
should result in SYS_exit.

as noted in commit 05870abeaac0588fb9115cfd11f96880a0af2108, the arm
version of __clone was broken in this case. in the past, the mips
version was also broken; it was fixed in commit
8b2b61e0001281be0dcd3dedc899bf187172fecb.

since this code path is pretty much entirely untested (previously only
reachable in applications that call the public clone() and return from
the start function) and consists of fragile per-arch asm, don't assume
it works, at least not until it's been thoroughly tested. instead make
the SYS_exit syscall from the start function's failure path.

fix %lf in wprintf

commit cc3a4466605fe8dfc31f3b75779110ac93055bc1 fixed this for printf
but neglected to fix wprintf.

Previously, %lf caused a failure to output.

fix arm __tlsdesc_dynamic when built as thumb code without __ARM_ARCH>=5

we don't actually support building asm source files as thumb1, but
it's possible that the condition __ARM_ARCH>=5 would be false on old
compilers that did not define __ARM_ARCH at all. avoiding that would
require enumerating all of the possible __ARM_ARCH_*__ macros for
testing.

as noted in commit 05870abeaac0588fb9115cfd11f96880a0af2108, mov lr,pc
is not valid for saving a return address when in thumb mode. since
this code is a hot path (dynamic TLS access), don't do the out-of-line
bl->bx chaining to save the return value; instead, use the fact that
this file is preprocessed asm to add the missing thumb bit with an add
in place of the mov.

the change here does not affect builds for ISA levels new enough to
have a thread pointer read instruction, or for armv5 and later as long
as the compiler properly defines __ARM_ARCH, or for any build as arm
(not thumb) code. it's likely that it makes no difference whatsoever
to any present-day practical build environments, but nonetheless now
it's safe.

as an alternative, we could just assume __thumb__ implies availability
of blx since we don't support building asm source files as thumb1. I
didn't do that in order to avoid having a wrong assumption here if
that ever changes.

fix arm __a_barrier_oldkuser when built as thumb

as noted in commit 05870abeaac0588fb9115cfd11f96880a0af2108, mov lr,pc
is not a valid method for saving the return address in code that might
be built as thumb.

this one is unlikely to matter, since any ISA level that has thumb2
should also have native implementations of atomics that don't involve
kuser_helper, and the affected code is only used on very old kernels
to begin with.

fix code path where child function returns in arm __clone built as thumb

mov lr,pc is not a valid way to save the return address in thumb mode
since it omits the thumb bit. use a chain of bl and bx to emulate blx.
this could be avoided by converting to a .S file with preprocessor
conditions to use blx if available, but the time cost here is
dominated by the syscall anyway.

while making this change, also remove the remnants of support for
pre-bx ISA levels. commit 9f290a49bf9ee247d540d3c83875288a7991699c
removed the hack from the parent code paths, but left the unnecessary
code in the child. keeping it would require rewriting two code paths
rather than one, and is useless for reasons described in that commit.

aarch64: add HWCAP2 flags from linux v5.2

AT_HWCAP2 flags, see

  linux commit 671db581815faf17cbedd7fcbc48823a247d90b1
  arm64: Expose DC CVADP to userspace

  linux commit 06a916feca2b262ab0c1a2aeb68882f4b1108a07
  arm64: Expose SVE2 features for userspace

add new syscall numbers from linux v5.2

new mount api syscalls were added, same numers on all targets, see

  linux commit a07b20004793d8926f78d63eb5980559f7813404
  vfs: syscall: Add open_tree(2) to reference or clone a mount

  linux commit 2db154b3ea8e14b04fee23e3fdfd5e9d17fbc6ae
  vfs: syscall: Add move_mount(2) to move mounts around

  linux commit 24dcb3d90a1f67fe08c68a004af37df059d74005
  vfs: syscall: Add fsopen() to prepare for superblock creation

  linux commit ecdab150fddb42fe6a739335257949220033b782
  vfs: syscall: Add fsconfig() for configuring and managing a context

  linux commit 93766fbd2696c2c4453dd8e1070977e9cd4e6b6d
  vfs: syscall: Add fsmount() to create a mount for a superblock

  linux commit cf3cba4a429be43e5527a3f78859b1bfd9ebc5fb
  vfs: syscall: Add fspick() to select a superblock for reconfiguration

  linux commit 9c8ad7a2ff0bfe58f019ec0abc1fb965114dde7d
  uapi, x86: Fix the syscall numbering of the mount API syscalls [ver #2]

  linux commit d8076bdb56af5e5918376cd1573a6b0007fc1a89
  uapi: Wire up the mount API syscalls on non-x86 arches [ver #2]

fcntl.h: add AT_RECURSIVE from linux v5.2

apply open_tree with OPEN_TREE_CLONE call to the entire subtree, see

  linux commit a07b20004793d8926f78d63eb5980559f7813404
  vfs: syscall: Add open_tree(2) to reference or clone a mount

fcntl.h: add AT_STATX_ statx sync flag definitions

see

  linux commit a528d35e8bfcc521d7cb70aaf03e1bd296c8493f
  statx: Add a system call to make enhanced file info available

these are linux specific and not reserved names for fcntl.h so they
are under _BSD_SOURCE|_GNU_SOURCE.

sched.h: add CLONE_PIDFD from linux v5.2

when set a pidfd is stored in parent_tidptr, see

  linux commit b3e5838252665ee4cfa76b82bdf1198dca81e5be
  clone: add CLONE_PIDFD

netinet/if_ether.h: add ETH_P_DSA_8021Q from linux v5.2

ethertype for fake VLAN header for DSA, see

  linux commit bf5bc3ce8a8f32a0d45b6820ede8f9fc3e9c23df
  ether: Add dedicated Ethertype for pseudo-802.1Q DSA tagging

honor __WCHAR_TYPE__ on archs with legacy long definition of wchar_t

historically, a number of 32-bit archs used long rather than int for
wchar_t, for no good reason. GCC still uses the historical types, but
clang replaced them all with int, and it seems PCC uses int too.
mismatching the compiler's type for wchar_t is not an option due to
wide string literals.

note that the mismatch does not affect C++ ABI since wchar_t is its
own builtin type/keyword in C++, distinct from both int and long, not
a typedef.

i386 already worked around this by honoring __WCHAR_TYPE__ if defined
by the compiler, and only using the official legacy ABI type if not.
add the same to the other affected archs.

it might make sense at some point to switch to using int as the
default if __WCHAR_TYPE__ is not defined, if the expectations is that
new compilers will treat int as the correct choice, but it's unlikely
that the case where __WCHAR_TYPE__ is undefined will ever be used
anyway. I actually wanted to move the definition of wchar_t to the
top-level shared alltypes.h.in, using __WCHAR_TYPE__ and falling back
to int if not defined, but that can't be done without assuming all
compilers define __WCHAR_TYPE__ thanks to some pathological archs
where the ABI has wchar_t as an unsigned type.

synchronously clean up pthread_create failure due to scheduling errors

previously, when pthread_create failed due to inability to set
explicit scheduling according to the requested attributes, the nascent
thread was detached and made responsible for its own cleanup via the
standard pthread_exit code path. this left it consuming resources
potentially well after pthread_create returned, in a way that the
application could not see or mitigate, and unnecessarily exposed its
existence to the rest of the implementation via the global thread
list.

instead, attempt explicit scheduling early and reuse the failure path
for __clone failure if it fails. the nascent thread's exit futex is
not needed for unlocking the thread list, since the thread calling
pthread_create holds the thread list lock the whole time, so it can be
repurposed to ensure the thread has finished exiting. no pthread_exit
is needed, and freeing the stack, if needed, can happen just as it
would if __clone failed.

set explicit scheduling for new thread from calling thread, not self

if setting scheduling properties succeeds, the new thread may end up
with lower priority than the caller, and may be unable to continue
running due to another intermediate-priority thread. this produces a
priority inversion situation for the thread calling pthread_create,
since it cannot return until the new thread reports success.

originally, the parent was responsible for setting the new thread's
priority; commits b8742f32602add243ee2ce74d804015463726899 and
40bae2d32fd6f3ffea437fa745ad38a1fe77b27e changed it as part of
trimming down the pthread structure. since then, commit
04335d9260c076cf4d9264bd93dd3b06c237a639 partly reversed the changes,
but did not switch responsibilities back. do that now.

fix unsynchronized decrement of thread count on pthread_create error

commit 8f11e6127fe93093f81a52b15bb1537edc3fc8af wrongly documented
that all changes to libc.threads_minus_1 were guarded by the thread
list lock, but the decrement for failed SYS_clone took place after the
thread list lock was released.

add public declaration for optreset under appropriate feature profiles

commit 030e52639248ac8417a4934298caa78c21a228d1 added optreset, a BSD
extension to getopt duplicating the functionality (also an extension)
of setting optind to 0, but failed to provide a public declaration for
it. according to the BSD documentation and headers, the application is
not supposed to need to provide its own declaration.

add posix_spawn [f]chdir file actions

these are presently extensions, thus named with _np to match glibc and
other implementations that provide them; however they are likely to be
standardized in the future without the _np suffix as a result of
Austin Group issue 1208. if so, both names will be kept as aliases.

add copy_file_range system call wrapper

fix clash between sys/user.h and kernel ptrace.h on powerpc[64], sh

due to historical accident/sloppiness in glibc, the powerpc,
powerpc64, and sh versions of struct user, defined by sys/user.h, used
struct pt_regs from the kernel asm/ptrace.h for their regs member.
this made it impossible to define the type in an API-compatible manner
without either including asm/ptrace.h like glibc does (contrary to our
policy of not depending on kernel headers), or clashing with
asm/ptrace.h's definition of struct pt_regs if both headers are
included (which is almost always the case in software using
sys/user.h).

for a long time I viewed this problem as having no reasonable fix. I
even explored the possibility of having the powerpc[64] and sh
versions of user.h just include the kernel header (breaking with
policy), but that looked like it might introduce new clashes with
sys/ptrace.h. and it would also bring in a lot of additional cruft
that makes no sense for sys/user.h to expose. glibc goes out of its
way to suppress some of that with #undef, possibly leading to
different problems. this is a rabbit-hole that should be explored no
further.

as it turns out, however, nothing actually uses struct user
sufficiently to care about the type of the regs member; most software
including sys/user.h does not even use struct user at all. so, the
problem can be fixed just by doing away with the insistence on strict
glibc API compatibility for the struct tag of the regs member.

rather than renaming the tag, which might lead to the new name
entering use as API, simply use an untagged structure inside struct
user with the same members/layout as struct pt_regs.

for sh, struct pt_dspregs is just removed entirely since it was not
used.

fix external dummy_lock symbol inadvertently introduced in sigaction

commit 9b14ad541068d4f7d0be9bcd1ff4c70090d868d3 introduced this
namespace violation.

remove sporadic server members from struct sched_param

these members are associated with an unsupported option group. with
time_t changing size on 32-bit archs, all interfaces taking struct
sched_param arguments would need redirection and compat shims in order
to be able to continue offering these members, for no benefit. just
convert them to reserved space instead.

re-add ELF gregs and fpregs types to riscv64 user.h

d493206de7df4db07ad34f24701539ba0a6ed38c deleted all the content of
user.h, but sys/procfs.h expects this from sys/user.h
threfore we retain the non conflicting parts

fix regression whereby main thread didn't get TLS relocations

commit ffab43602b5900c86b7040abdda8ccf6cdec95f5 broke this by moving
relocations after not only the allocation of storage for the main
thread's static TLS, but after the copying of the TLS image. thus,
relocation results were not reflected in the main thread's copy. this
could be fixed by calling __reset_tls after relocations, but instead
split the allocation and installation before/after relocations so that
there's not a redundant copy.

due to commit 71af5309874269bcc9e4b84ea716fab33d888c1d, updating of
static_tls_cnt needs to be kept with allocation of static TLS, before
relocations, rather than after installation.

fix accidentlly-external cmp symbol introduced with catgets

commit 7590203c486d9002522019045d34ee3dee0a66f5 omitted static here.

make relocation time symbol lookup and dlsym consistent

Using common code path for all symbol lookups fixes three dlsym issues:

- st_shndx of STT_TLS symbols were not checked and thus an undefined
  tls symbol reference could be incorrectly treated as a definition
  (the sysv hash lookup returns undefined symbols, gnu does not, so should
  be rare in practice).

- symbol binding was not checked so a hidden symbol may be returned
  (in principle STB_LOCAL symbols may appear in the dynamic symbol table
  for hidden symbols, but linkers most likely don't produce it).

- mips specific behaviour was not applied (ARCH_SYM_REJECT_UND) so
  undefined symbols may be returned on mips.

always_inline is used to avoid relocation performance regression, the
code generation for find_sym should not be affected.

ldso: correct condition for local symbol handling in do_relocs

commit 7a9669e977e5f750cf72ccbd2614f8b72ce02c4c added use of the
symbol reference as the definition, in place of performing a lookup,
for STT_SECTION symbol references that were first found used in FDPIC.
such references may happen in certain other cases, such as
local-dynamic TLS and with relocation types that require a symbol but
that are being used for non-symbolic purposes, like the powerpc
unaligned address relocations.

in all such cases I'm aware of, the symbol referenced is a section
symbol (STT_SECTION); however, the important semantic property is not
its being a section, but rather its binding local (STB_LOCAL). check
the latter instead of the former for greater generality and semantic
correctness.

add support for powerpc/powerpc64 unaligned relocations

R_PPC_UADDR32 (R_PPC64_UADDR64) has the same meaning as R_PPC_ADDR32
(R_PPC64_ADDR64), except that its address need not be aligned. For
powerpc64, BFD ld(1) will automatically convert between ADDR<->UADDR
relocations when the address is/isn't at its native alignment. This
will happen if, for example, there is a pointer in a packed struct.

gold and lld do not currently generate R_PPC64_UADDR64, but pass
through misaligned R_PPC64_ADDR64 relocations from object files,
possibly relaxing them to misaligned R_PPC64_RELATIVE. In both cases
(relaxed or not) this violates the PSABI, which defines the relevant
field type as "a 64-bit field occupying 8 bytes, the alignment of
which is 8 bytes unless otherwise specified."

All three linkers violate the PSABI on 32-bit powerpc, where the only
difference is that the field is 32 bits wide, aligned to 4 bytes.

Currently musl fails to load executables linked by BFD ld containing
R_PPC64_UADDR64, with the error "unsupported relocation type 43".
This change provides compatibility with BFD ld on powerpc64, and any
static linker on either architecture that starts following the PSABI
more closely.

ldso: remove redundant runtime checks in static TLS logic

as a result of commit ffab43602b5900c86b7040abdda8ccf6cdec95f5,
static_tls_cnt is now valid during relocations at program startup, so
it's no longer necessary to condition the check against static_tls_cnt
on this being a runtime (dlopen) relocation.