This is a prerequisite for upstreaming our LLVM patches, as our current
hack forcing `-ftls-model=initial-exec` in the Clang driver is not
acceptable upstream.
Currently, our kernel-managed TLS implementation limits us to only
having a single block of storage for all thread-local variables that's
initialized at load time. This PR merely implements the dynamic TLS
interface (`__tls_get_addr` and TLSDESC) on top of our static TLS
infrastructure. The current model's limitations still stand:
- a single static TLS block is reserved at load time, `dlopen()`-ing
shared libraries that define thread-local variables might cause us to
run out of space.
- the initial TLS image is not changeable post-load, so `dlopen()`-ing
libraries with non-zero-initialized TLS variables is not supported.
The way we repurpose `ti_module` to mean "offset within static TLS
block" instead of "module index" is not ABI-compliant.
In C++, a function declaration with an empty parameter list means that
the function takes no arguments. In C, however, it means that the
function takes an unspecified number of parameters.
What we did previously was therefore non-conforming. This caused a
config check to fail in the curl port, as it was able to redeclare
`rand` as taking an int parameter.
Previously, getauxval() got the address of the auxiliary vector by
traversing to the end of the `environ` pointer.
The assumption that the auxiliary vector comes after the environment
array is true at program startup, however the environment array may
be re-allocated and change its address during runtime which would cause
getauxval() to work with an incorrect auxiliary vector address.
To fix this, we now get the address of the auxiliary vector once in
__libc_init and store it in a libc-internal pointer which is then used
by getauxval().
Fixes#10087.
If we hit an assertion while the heap isn't in a stable state, we can't
rely on dynamic memory allocation because the malloc mutex is already
held and the heap is most likely corrupted. Instead, we need to bail
out fast before we make the situation even worse.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
