And avoid a Hurd build failures. Checked on x86_64-linux-gnu.
While working on a patch to add support for the extensible rseq ABI, we
came across an issue where a new 'const' variable would be merged with
the existing '__rseq_size' variable. We tracked this to the use of
'-fmerge-all-constants' which allows the compiler to merge identical
constant variables. This means that all 'const' variables in a compile
unit that are of the same size and are initialized to the same value can
be merged.
In this specific case, on 32 bit systems 'unsigned int' and 'ptrdiff_t'
are both 4 bytes and initialized to 0 which should trigger the merge.
However for reasons we haven't delved into when the attribute 'section
(".data.rel.ro")' is added to the mix, only variables of the same exact
types are merged. As far as we know this behavior is not specified
anywhere and could change with a new compiler version, hence this patch.
Move the definitions of these variables into an assembler file and add
hidden writable aliases for internal use. This has the added bonus of
removing the asm workaround to set the values on rseq registration.
Tested on Debian 12 with GCC 12.2.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Starting with commit 59974938fe1f4add843f5325f78e2a7ccd8db853 elf/rtld: Count skipped environment variables for enable_secure The new testcase elf/tst-tunables-enable_secure-env segfaults on s390 (31bit). There _start parses the auxiliary vector for some additional checks. Therefore it skips over the zeros after the environment variables ... 0x7fffac20: 0x7fffbd17 0x7fffbd32 0x7fffbd69 0x00000000 ------------------------------------------------^^^last environment variable ... and then it parses the auxiliary vector and stops at AT_NULL. 0x7fffac30: 0x00000000 0x00000021 0x00000000 0x00000000 --------------------------------^^^AT_SYSINFO_EHDR--------------^^^AT_NULL ----------------^^^newp-----------------------------------------^^^oldp Afterwards it tries to access AT_PHDR which points to somewhere and segfaults. Due to not incorporating the skip_env variable in the computation of oldp when shuffling down the auxv in rtld.c, it just copies one entry with AT_NULL and value 0x00000021 and stops the loop. In reality we have skipped GLIBC_TUNABLES environment variable (=> skip_env=1). Thus we should copy from here: 0x7fffac40: 0x00000021 0x7ffff000 0x00000010 0x007fffff ----------------^^^fixed-oldp This patch fixes the computation of oldp when shuffling down auxiliary vector. It also adds some checks in the testcase. Those checks also fail on s390x (64bit) and x86_64 without the fix. Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It turns out that quite a few applications use bundled mallocs that
have been built to use global-dynamic TLS (instead of the recommended
initial-exec TLS). The previous workaround from
commit afe42e935b3ee97bac9a7064157587777259c60e ("elf: Avoid some
free (NULL) calls in _dl_update_slotinfo") does not fix all
encountered cases unfortunatelly.
This change avoids the TLS generation update for recursive use
of TLS from a malloc that was called during a TLS update. This
is possible because an interposed malloc has a fixed module ID and
TLS slot. (It cannot be unloaded.) If an initially-loaded module ID
is encountered in __tls_get_addr and the dynamic linker is already
in the middle of a TLS update, use the outdated DTV, thus avoiding
another call into malloc. It's still necessary to update the
DTV to the most recent generation, to get out of the slow path,
which is why the check for recursion is needed.
The bookkeeping is done using a global counter instead of per-thread
flag because TLS access in the dynamic linker is tricky.
All this will go away once the dynamic linker stops using malloc
for TLS, likely as part of a change that pre-allocates all TLS
during pthread_create/dlopen.
Fixes commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow
tls access after dlopen [BZ #19924]").
Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
The conditionals for several mtrace-based tests in catgets, elf, libio, malloc, misc, nptl, posix, and stdio-common were incorrect leading to test failures when bootstrapping glibc without perl. The correct conditional for mtrace-based tests requires three checks: first checking for run-built-tests, then build-shared, and lastly that PERL is not equal to "no" (missing perl). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Remove the definitions of HWCAP_IMPORTANT after removal of LD_HWCAP_MASK / tunable glibc.cpu.hwcap_mask. There HWCAP_IMPORTANT was used as default value. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Remove the environment variable LD_HWCAP_MASK and the tunable glibc.cpu.hwcap_mask as those are not used anymore in common-code after removal in elf/dl-cache.c:search_cache(). The only remaining user is sparc32 where it is used in elf_machine_matches_host(). If sparc32 does not need it anymore, we can get rid of it at all. Otherwise we could also move LD_HWCAP_MASK / tunable glibc.cpu.hwcap_mask to be sparc32 specific. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Despite of powerpc where the returned integer is stored in tcb, and the diagnostics output, there is no user anymore. Thus this patch removes the diagnostics output and _dl_string_platform for all other platforms. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The legacy hwcaps mechanism was removed with glibc 2.37: See this commit series: - d178c67535f0d159df73843e7c18cbdb39b4d25d x86_64: Remove platform directory library loading test - 6099908fb84debee4c3bcb05d88769410c2aecd1 elf: Remove legacy hwcaps support from the dynamic loader - b78ff5a25dc8ba9d8c6df10bb0a533254bdd193f elf: Remove legacy hwcaps support from ldconfig - 4a7094119ce05cadf927f52cc5d723e2195e65f9 elf: Remove hwcap parameter from add_to_cache signature - cfbf883db36727a84ef7929af49ef68c195b5972 elf: Remove hwcap and bits_hwcap fields from struct cache_entry - 78d9a1620b840deb0880686e4159eaf70708866a Add NEWS entry for legacy hwcaps removal - ab40f20364f4a417a63dd51fdd943742070bfe96 elf: Remove _dl_string_hwcap - e76369ed6371734f77f468eab097ef4e5b5db1c5 elf: Simplify output of hwcap subdirectories in ld.so help According to Florian Weimer, this was an oversight and should also have been removed. As ldconfig does not generate ld.so.cache entries with hwcap/platform bits in the hwcap-field anymore, this patch now skips those entries. Thus currently only named-hwcap-entries and the default entries are allowed. For named-hwcap entries bit 62 is set and also the isa-level bits can be set. For the default entries the hwcap-field is 0. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>