This fixes an error in 6af4f25b899e89e4b91f8c197ae5a6ce04bcce7b: The
r0 register is special in addressing modes on s390x and is interpreted
as constant zero, i.e. lg %r5, 8(%r0) would effectively become lg %r5,
8. So care should be taken to never use r0 as an address register in
s390x assembly.

as stated in the comment added, the ABI for SME requires libc to be
aware of and support the extension to the register file. this is
necessary to handle lazy saving correctly across setjmp/longjmp, and
on older kernels, in order not to introduce memory corruption bugs
that may be exploitable vulnerabilities when creating new threads.

previously, we did not expose __getauxval, the interface libgcc uses
to determine runtime availability of SME, so it was not usable when
following the intended ABI. since commit
ab4635fba6769e19fb411a1ab3c8aa7407e11188 has now exposed this
interface, a mitigation is needed to ensure SME is not used
unless/until we have proper support for it.

while SME is the current hwcap feature that needs this treatment,
as-yet-undefined hwcap bits are also masked in case other new cpu
features have similar ABI issues. this could be re-evaluated at some
point in the future.

for now, the masking is only on aarch64. arguably it should be
considered for all archs, but whether it's needed is really a matter
of how ABI policy & stability are handled by the maintainers of the
arch psABI, and aarch64 is the one that's demonstrated a necessity. if
it turns out something like this is needed for more/all archs, making
a generalized framework for it would make sense. for now, it's stuffed
into __set_thread_area the same way atomics detection is stuffed there
for 32-bit arm and sh, as it's a convenient point for "arch-specific
early setup code" without invasive changes.

this change both aligns with the intended future direction for most
assembly usage, and makes it possible to add arch-specific setup logic
based on hwcaps like we have for 32-bit arm.

the alias fp is only supported on some assemblers. use the actual
register name x29 instead.

This just mirrors what is done in the start code for the affected
ports, as well as what is already done for the three x86 ports.

Clearing the frame pointer helps protect FP-based unwinders from
wrongly attempting to traverse into the parent thread's call frame
stack.

This was an oversight specific to these archs; others have always
aligned the new stack pointer correctly.

Calling __tls_get_addr with brasl is not valid since it's a global symbol; doing
so results in an R_390_PC32DBL relocation error from lld. We could fix this by
marking __tls_get_addr hidden since it is not part of the s390x ABI, or by using
a different instruction. However, given its simplicity, it makes more sense to
just manually inline it into __tls_get_offset for performance.

The patch has been tested by applying to Zig's bundled musl copy and running the
full Zig test suite under qemu-s390x.

if sem_post is interrupted between clearing the waiters bit from the
semaphore value and performing the futex wait operation, subsequent
calls to sem_post will not perform a wake operation unless a new
waiter has arrived.

usually, this is at most a minor nuisance, since the original wake
operation will eventually happen. however, it's possible that the wake
is delayed indefinitely if interrupted by a signal handler, or that
the address the wake needs to be performed on is no longer mapped if
the semaphore was a process-shared one that has since been unmapped
but has a waiter on a different mapping of the same semaphore. this
can happen when another thread using the same mapping "steals the
post" atomically before actually becoming a second waiter, deduces
from success that it was the last user of the semaphore mapping, then
re-posts and unmaps the semaphore mapping. this scenario was described
in a report by Markus Wichmann.

instead of checking only the waiters bit, also check the waiter count
that was sampled before the atomic post operation, and perform the
wake if it's nonzero. this will not produce any additional wakes under
non-race conditions, since the waiters bit only becomes zero when
targeting a single waiter for wake. checking both was already the
behavior prior to commit 159d1f6c02569091c7a48bdb2e2e824b844a1902.

Identical to riscv64 except for stack offsets in clone.

According to LoongArch ABI Specs, stack need to be 16 align to improve
performance and compiler layout of stack frames.