see linux commit e8c24d3a23a469f1f40d4de24d872ca7023ced0a
and linux Documentation/x86/protection-keys.txt

the static-linked version of __init_tls needs to locate the TLS
initialization image via the ELF program headers, which requires
determining the base address at which the program was loaded. the
existing code attempted to do this by comparing the actual address of
the program headers (obtained via auxv) with the virtual address for
the PT_PHDR record in the program headers. however, the linker seems
to produce a PT_PHDR record only when a program interpreter (dynamic
linker) is used. thus the computation failed and used the default base
address of 0, leading to a crash when trying to access the TLS image
at the wrong address.

the dynamic linker entry point and static-PIE rcrt1.o startup code
compute the base address instead by taking the difference between the
run-time address of _DYNAMIC and the virtual address in the PT_DYNAMIC
record. this patch copies the approach they use, but with a weak
symbolic reference to _DYNAMIC instead of obtaining the address from
the crt_arch.h asm. this works because relocations have already been
performed at the time __init_tls is called.

all assembly is now thumb2-compatible. on existing targets this is at
best a size optimization, but it will also facilitate porting to
thumb2-isa-only arm variants.

three problems are addressed:

- use of pc arithmetic, which was difficult if not impossible to make
  correct in thumb mode on all models, so that relative rather than
  absolute pointers to the backends could be used. this was designed
  back when there was no coherent model for the early stages of the
  dynamic linker before relocations, and is no longer necessary.

- assumption that data (the relative pointers to the backends) can be
  accessed at a constant displacement from the code. this will not be
  possible on future fdpic subarchs (for cortex-m), so move
  responsibility for loading the backend code address to the caller.

- hard-coded arm opcodes using the .word directive. instead, use the
  .arch directive to work around the assembler's refusal to assemble
  instructions not available (or in some cases, available but just
  considered deprecated) in the target isa level. the obscure v6t2
  arch is used for v6 code so as to (1) allow generation of thumb2
  output if -mthumb is active, and (2) avoid warnings/errors for mcr
  barriers that clang would produce if we just set arch to v7-a.

in addition, the __aeabi_read_tp function is moved out of the inner
workings and implemented as an asm wrapper around a C function, so
that asm code does not need to read global data. the asm wrapper
serves to satisfy the ABI calling convention requirements for this
function.

the thumb incompatibilities in the asm are probably only minor and
should be fixable, but for now just use the C version.

sp cannot be used in the ldm/stm register set in thumb mode.

float conversion is slow and big on soft-float targets.

The lookup table increases code size a bit on most hard float targets
(and adds 60byte rodata), performance can be a bit slower because of
position independent data access and cpu internal state dependence
(cache, extra branches), but the overall effect should be minimal
(common, small size allocations should be unaffected).

In BRE, ^ is an anchor at the beginning of an expression, optionally
it may be an anchor at the beginning of a subexpression and must be
treated as a literal otherwise.

Previously musl treated ^ in subexpressions as literal, but at least
glibc and gnu sed treats it as an anchor and that's the more useful
behaviour: it can always be escaped to get back the literal meaning.

Same for $ at the end of a subexpression.

Portable BRE should not rely on this, but there are sed commands in
build scripts which do.

This changes the meaning of the BREs:

	\(^a\)
	\(a\|^b\)
	\(a$\)
	\(a$\|b\)

POSIX specifies the result to have signed 32-bit range. on 32-bit
archs, the implicit conversion to long achieved the desired range
already, but when long is 64-bit, a cast is needed.

patch by Ed Schouten.

the bz instruction that was wrongly used only admits a small immediate
displacement and cannot be used with external symbols; apparently the
linker fails to diagnose the overflow.

this has been slated for removal for a long time. there is
fundamentally no way to implement stdarg without compiler assistance;
any attempt to do so has serious undefined behavior; its working
depends not just (as a common misconception goes) on ABI, but also on
assumptions about compiler code generation internal to a translation
unit, which is not subject to external ABI constraints.

gdb can only backtrace/unwind across signal handlers if it recognizes
the sa_restorer trampoline. for x86_64, gdb first attempts to
determine the symbol name for the function in which the program
counter resides and match it against "__restore_rt". if no name can be
found (e.g. in the case of a stripped binary), the exact instruction
sequence is matched instead.

when matching the function name, however, gdb's unwind code wrongly
considers the interval [sym,sym+size] rather than [sym,sym+size).
thus, if __restore_rt begins immediately after another function, gdb
wrongly identifies pc as lying within the previous adjacent function.
this patch adds a nop before __restore_rt to preclude that
possibility. it also removes the symbol name __restore and replaces it
with a macro since the stability of whether gdb identifies the
function as __restore_rt or __restore is not clear.

for the no-symbols case, the instruction sequence is changed to use
%rax rather than %eax to match what gdb expects.

based on patch by Szabolcs Nagy, with extended description and
corresponding x32 changes added.

On s390x, the kernel provides AT_SYSINFO_EHDR, but sets it to zero, if the
program being run does not have a program interpreter.  This causes
problems when running the dynamic linker directly.

alpha and s390x gratuitously use 64-bit entries (wasting 2x space and
cache utilization) despite the values always being 32-bit.

based on patch by Bobby Bingham, with changes suggested by Alexander
Monakov to use the public Elf_Symndx type from link.h (and make it
properly variable by arch) rather than adding new internal
infrastructure for handling the type.

commit 31fb174d used
DEFAULT_GUARD_SIZE from pthread_impl.h in a static initializer,
breaking build on archs where its definition, PAGE_SIZE, is not a
constant. instead, just define DEFAULT_GUARD_SIZE as 4096, the minimal
page size on any arch we support. pthread_create rounds up to whole
pages anyway, so defining it to 1 would also work, but a moderately
meaningful value is nicer to programs that use
pthread_attr_getguardsize on default-initialized attribute objects.

based on patch by Timo Teräs:

While generally this is a bad API, it is the only existing API to
affect c++ (std::thread) and c11 (thrd_create) thread stack size.
This patch allows applications only to increate stack and guard
page sizes.

commit 33ce9208 broke pthread_create
in the case where a null attribute pointer is passed; rather than
using the default sizes, sizes of 0 (plus the remainder of one page
after TLS/TCB use) were used.

the linux kernel uapi headers provide their own definitions of the
structures from netinet/in.h, resulting in errors when a program
includes both the standard libc header and one or more of the
networking-related kernel headers that pull in the kernel definitions.

as before, we do not attempt to support the case where kernel headers
are included before the libc ones, since the kernel definitions may
have subtly incorrect types, namespace violations, etc. however, we
can easily support the inclusion of the kernel headers after the libc
ones, since the kernel headers provide a public interface for
suppressing their definitions. this patch adds the necessary macro
definitions for such suppression.

previously, the pthread_attr_t object was always initialized all-zero,
and stack/guard size were represented as differences versus their
defaults. this required lots of confusing offset arithmetic everywhere
they were used. instead, have pthread_attr_init fill in the default
values, and work with absolute sizes everywhere.

the swprintf write callback never reset its buffer pointers, so after
its 256-byte buffer filled up, it would keep repeating those bytes
over and over in the output until the destination buffer filled up. it
also failed to set the error indicator for the stream on EILSEQ,
potentially allowing output to continue after the error.

the overflow check for years+100 did not account for the extra
year computed from the remaining months. instead, perform this
check after obtaining the final number of years.

If a DT_NEEDED entry was the prefix of a reserved library name
(up to the first dot) then it was incorrectly treated as a libc
reserved name.

e.g. libp.so dependency was not loaded as it matched libpthread
reserved name.

this was harmless as load_library is not called concurrently,
but it used one word of bss.

the value 19991006 for __RES implies availability of res_ninit and
related functions that take a resolver state argument; these are not
supported since our resolver is stateless. instead claim support for
just the older API by defining __RES to 19960801.

based on patch by Dmitrij D. Czarkoff.

Fix parsing of the < > quoted time zone names. Compare the correct
character instead of repeatedly comparing the first character.

this header is XSI-shaded itself and thus does not need to limit
specific content to _XOPEN_SOURCE.

the old snprintf design setup the FILE buffer pointers to point
directly into the destination buffer; if n was actually larger than
the buffer size, the pointer arithmetic to compute the buffer end
pointer was undefined. this affected sprintf, which is implemented in
terms of snprintf, as well as some unusual but valid direct uses of
snprintf.

instead, setup the FILE as unbuffered and have its write function
memcpy to the destination. the printf core sets up its own temporary
buffer for unbuffered streams.

reported and changes suggested by Daniel Sabogal.

inclusion of these names was unintentional and in most cases is a
namespace violation. Daniel Sabogal tracked down and reported these.

ETH_P_HSR (IEC 62439-3 HSRv1) added in
linux 4.7 commit ee1c27977284907d40f7f72c2d078d709f15811f

ETH_P_TSN (IEEE 1722) added in
linux 4.3 commit 1ab1e895492d8084dfc1c854efacde219e56b8c1
this constant breaks the ascending order to match the kernel header

ETH_P_XDSA (Multiplexed DSA protocol) added in
linux 3.18 commit 3e8a72d1dae374cf6fc1dba97cec663585845ff9

ARPHRD_6LOWPAN (IPv6 over LoWPAN) added in
linux 3.14 commit 0abc652c796dab74d34d60473ec5594cd21620be

the _CS_V6_ENV and _CS_V7_ENV constants are required to be available for use
with confstr. glibc defines these constants with values 1148 and 1149,
respectively.

the only missing (and required) confstr constants are
_CS_POSIX_V7_THREADS_CFLAGS and _CS_POSIX_V7_THREADS_LDFLAGS which remain
unavailable in glibc.

commit 6ffdc457 set lnz in the code
path for non-zero digits after a huge string of zeros, but the
assignment of dc to lnz truncates if the value of dc does not fit in
int; this is possible for some pathologically long inputs, either via
strings on 64-bit systems or via scanf-family functions.

instead, simply set lnz to match the point at which we add the
artificial trailing 1 bit to simulate nonzero digits after a huge
run of zeros.