This avoids a regression in the omnetpp and xalancbmk benchmarks
of SPEC. Apparently, these benchmarks are very sensitive to the
fill rate in malloc.
Suggested-by: Wilco Dijkstra <wilco.dijkstra@arm.com>
Tested-by: Wilco Dijkstra <wilco.dijkstra@arm.com>
Batched frees amortize the locking overhead once the tcache is full.
Previously, once the tcache slot was full, each free acquired the
arena lock. With this change, neighboring tcache allocations in the
same arena re-use an arena lock that already exists.
Pass the tcache pointer to __libc_free_batch so that it is not
necessary to reload the tcache pointer after the _int_free_chunk
calls.
Both ld.so and malloc track kernel THP mode and THP page size when THP
in ld.so is enabled by
GLIBC_TUNABLES=glibc.elf.thp=1
and THP in malloc is enabled by
GLIBC_TUNABLES=glibc.malloc.hugetlb=1
But DL_MAP_DEFAULT_THP_PAGESIZE and MALLOC_DEFAULT_THP_PAGESIZE may be
different when they are defined in <hugepages.h>.
If THP in ld.so is enabled, change malloc to use kernel THP mode from
ld.so, instead of calling __get_thp_mode, and use THP page size from
ld.so if it came from __get_thp_size. This avoids calling __get_thp_mode
and __get_thp_size again, which are quite expensive:
1. Initialize mp_.thp_mode and GL(dl_thp_mode) to thp_mode_unknown.
2. Set mp_.thp_mode to GL(dl_thp_mode) if GL(dl_thp_mode) isn't
thp_mode_unknown. Otherwise call __get_thp_mode to set mp_.thp_mode.
3. GL(dl_elf_thp_pagesize) is set to DL_MAP_DEFAULT_THP_PAGESIZE without
calling __get_thp_size and THP page size for malloc may be different from
THP page size for ld.so. Set mp_.thp_pagesize to GL(dl_elf_thp_pagesize)
if DL_MAP_DEFAULT_THP_PAGESIZE is defined. Otherwise call __get_thp_size
to set mp_.thp_pagesize.
4. THP page size in malloc is capped to MAX_THP_PAGESIZE. If THP page
size is above MAX_THP_PAGESIZE, THP in malloc is disabled.
These result in when glibc.elf.thp is set to 1, malloc uses the actual
kernel THP mode instead of defaulting to madvise mode and madvise_thp
will stop issuing MADV_HUGEPAGE if kernel THP mode is always.
This fixes BZ #34083.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
When scanf parses special floating-point inputs like "nan", "inf", it
may read one extra character to check whether the input still matches
the expected word.
If that extra character does not match, the conversion should fail, but
the character has already been read from the stream. Some error paths
did not push it back before reporting the conversion error, so later input
started at the wrong position.
Fix this by keeping EOF and width errors separate from character mismatch
errors. Push the character back before calling conv_error for mismatch
errors.
Add narrow and wide scanf tests using the same test body. The test cases
focus on the paths changed by this patch: mismatches while matching "nan",
"nan(...)", "inf", and "infinity".
Tested on x86_64 Fedora 42.
The following tests passed without regressions:
make test t=stdio-common/tst-scanf-bz34208
make test t=stdio-common/tst-wscanf-bz34208
make subdirs="stdio-common libio" check
Signed-off-by: Xiang Gao <gaoxiang@kylinos.cn>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Since the NSS reorganization in glibc 2.33 the --enable-static-nss
option no longer changes the build: the files and dns services are built
into libc unconditionally, and there is no longer any mechanism to bake
the remaining services into libc.a. After removing the dead
-DSTATIC_NSS define and the <gnu/lib-names.h> include (commits
82b710c190 and
2169401438), the option's only remaining
effect was to define DO_STATIC_NSS, which suppresses the static link
warnings on the NSS interface functions in libc.a.
With DO_STATIC_NSS gone, nss_interface_function emits the static link
warning unconditionally; static_nss and build-static-nss are removed
along with the configure option.
tst-nss-static, previously built only when build-static-nss was set, is
now added to tests-static unconditionally so the static NSS path retains
test coverage.
Signed-off-by: Michael Ford <fanquake@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Add a new section to the Dynamic Linker chapter describing the
STT_GNU_IFUNC mechanism: the resolver calling convention for each
supported architecture, when resolvers run, and the functionality
supported in resolvers (TLS access, stack protector, cross-object
references) along with the remaining restrictions, reflecting the
recent ordering fixes (BZ 20680, BZ 23240, BZ 28817, BZ 34164,
BZ 34170). Also cross-reference it from the hardening section.
Reviewed-by: Yury Khrustalev <yury.khrustalev@arm.com>
Restore the POWER10 memchr implementation reverted in commit
a7877bb668 [BZ #33059], addressing the
actual cause:
The non-volatile vector register v20 used as the
zero vector (M_VREG_ZERO) is replaced with the volatile register v17.
Additionally, the assembler workaround used earlier for the
instructions lxvp and vextractbm is replaced with actual
instructions.
The RISC-V libthread_db THREAD_SELF descriptor currently assumes 64-bit
general-register slots:
REGISTER (64, 64, 4 * 8, ...)
That is correct for RV64, where tp/x4 is at byte offset 4 * 8 in the
general register set. On RV32, general-register slots are 32-bit wide,
so tp/x4 is at byte offset 4 * 4.
Using the RV64 layout on RV32 makes libthread_db read the wrong thread
pointer value and prevents GDB from enabling pthread-aware thread
debugging.
Use a helper macro to pass the RISC-V register size into the
DB_THREAD_SELF definition.
Signed-off-by: Shengwen Cheng <shengwen1997.tw@gmail.com>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
Since R_ARC_S25W_PCREL range is limited, 32MB THP code padding leads to
relocation overflow:
.../support/libsupport_nonshared.a(support_test_main.oS):
in function `support_test_main':
.../support/support_test_main.c:396:(.text+0x650): relocation truncated to fit: R_ARC_S25W_PCREL_PLT against symbol `atexit' defined in .text section in
../glibc/libc_nonshared.a(atexit.oS)
.../install/compilers/arc-linux-gnu/arc-glibc-linux-gnu/bin/ld: final link failed
collect2: error: ld returned 1 exit status
Limit THP code padding to 2 * THP page size to avoid R_ARC_S25W_PCREL
relocation overflow.
Tested natively for Linux/x86-64 and Linux/i686 as well as with
build-many-glibcs.py for arc-linux-gnu.
This fixes BZ #34311
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The new structure matches that of Arm Optimized-routines,
to facilitate files traceability.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The feupdateenv function is supposed to raise exceptions after
installing the environment represented by its envp argument.
This was accidentally missed on hppa.
The failure to raise exceptions was noticed by the failure of
the math/test-narrowing-trap test.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Add a test for the buffer overflow in gethostbyname_r (Bug 18287), which
occurs when alignment padding is not subtracted from the remaining buffer
length.
The test uses binary search to find the exact required buffer size
for a mocked DNS response. It then tests all pointer misalignments
(1-7 bytes) using a custom 0xAA guard region. This guarantees
deterministic detection of out-of-bounds writes, avoiding false
negatives caused by malloc chunk rounding.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Change the definition of _PATH_MOUNTED to "/etc/mtab". This is the
value used on Linux, and BSD also uses /etc/mtab.
The change is motivated by the fact that on Debian /etc/mtab is a
symbolic link to /proc/mounts. This patch adjusts the macro for
non-linux systems such as Hurd. Changing this using
sysdeps/mach/hurd/paths.h causes build problems because
/usr/include/hurd/paths.h is shadowed by this file. This change is
proposed in the hope that aligning the non-linux targets with the
glibc for Linux is perceived as a good thing while fixing this problem
on Debian/Hurd along the way.
The parse_tilde function previously used strndupa to allocate memory
for the parsed username on the stack, and since the input is
user-defined, this can lead to a stack overflow.
This patch fixes the issue by replacing strndupa with scratch_buffer,
by reusing the buffer used in the __getpwnam_r call.
The new “tst-wordexp-tilde.c” test is a test-container to avoid using
system-defined NSS modules.
Checked on x86_64-linux-gnu and i686-linux-gnu.
This patch adds an RVV-optimized implementation of memmove for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__memmove_vector) is added
alongside the generic fallback (__memmove_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling memmove().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
The current THP segment load approach works only when THP is enabled
with always in the kernel. If THP is enabled with madvise in the
kernel, to enable THP segment load in an application, madvise should
be called with MADV_HUGEPAGE on all THP eligible PT_LOAD segments:
1. Define DL_MAP_DEFAULT_THP_PAGESIZE in hugepages.h and default it to 0.
If DL_MAP_DEFAULT_THP_PAGESIZE is defined, assume kernel THP madvise mode.
If kernel THP mode is always or never, there is an extra madvise call
which has no impact. DL_MAP_DEFAULT_THP_PAGESIZE is defined for x86-64
and 64-bit loongarch.
2. Update _dl_map_segment_align to support madvise THP mode. This fixes
BZ #34079.
3. Call _dl_executable_postprocess in rtld_setup_main_map for dynamic
executables and in LIBC_START_MAIN for static executables, which calls
madvise with MADV_HUGEPAGE on all THP eligible PT_LOAD segments in
executable. This fixes BZ #34080 for both dynamic and static executables.
4. Call _dl_postprocess_loadcmd_extra in _dl_postprocess_loadcmd, which
calls madvise with MADV_HUGEPAGE on all THP eligible PT_LOAD segments
when loading an object after they have been mapped in. This fixes
BZ #34080 for shared objects.
5. Set the maximum page alignment on THP tests to THP page size as the
default maximum page alignment may be smaller than THP page size.
6. Add tests to verify that large executable PT_LOAD segments in
executables are mapped at addresses aligned to THP page size when the
kernel is configured to use THP in "always" mode or "madvise" mode by
inspecting /proc/self/maps to check that the mapping address is aligned
to THP page size reported by the kernel. Also verify that madvise is
called with MADV_HUGEPAGE when the glibc tunable glibc.elf.thp=1 is used
and madvise isn't called with MADV_HUGEPAGE when the glibc tunable
glibc.elf.thp=0 is used.
Skip these tests if THP page size cannot be determined or if THP is not
enabled in "always" mode nor "madvise" mode.
Quote WANG Rui <wangrui@loongson.cn>:
From benchmarking a clang build of the Linux kernel on x86_64 with
your patch in THP madvise mode, I observed that iTLB misses were
reduced, similar to what we see in THP always mode.
NB: Some THP tests fail on arm due to limitations of arm32 kABI:
https://sourceware.org/bugzilla/show_bug.cgi?id=34096
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Commit a5ec880f80 ("Consolidate pointer
guard to use a relro variable instead of the TCB") moved the pointer
guard to the module-local relro variable __pointer_chk_guard_local and
dropped the THREAD_{SET,COPY}_POINTER_GUARD macros, which are no longer
defined by any target.
Checked on a build for all afftected targets.
This test case covers both input buffer overreads and output buffer
overflows. It should systematically cover these issues.
I used code auto-generation for updating the test expectations for
truncated RDATA in TXT, ISDN records, after writing the rest
of the test by hand.
Assisted-by: LLM
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Check that the RDATA payload does not require more than RDATALEN
bytes while processing it. The fixes cover A6, LOC records.
(CERT, TKEY, TSIG were fixed before, by switching to the generic
formatter.)
The vulnerable LOC record handling was first introduced before
glibc 2.0, in commit ee188d555b.
CERT, TSIG, TKEY handling came with commit
b43b13ac25, released with glibc 2.2.
A6 record handling was introduced in commit
9163381643 ("* resolv/ns_print.c
(ns_sprintrrf): Handle ns_t_a6 and ns_t_opt."), which went into glibc
2.7.
This fixes bug 34069.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This makes the output more consistent (either failure or complete
output) and helps with systematic testing with varying buffer
sizes.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Do not add the "unknown RR type" comment. After adding the TYPE
prefix, the number is largely redundant.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The p_class and p_type results could overwrite each other if both
were unknown. Format unknown values with CLASS and TYPE prefixes,
as in RFC 3597. Handle A6 separately because it cannot be added
to __p_type_syms for ABI reasons.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It turns out there is a missing inner length check in it, too.
Also fix the vulnerable commit. It predates the glibc 2.0 release
because the old stream-based formatting code in resolv/res_debug.c had
the same bug in its LOC handling.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Add matches before the start to ensure the memchr test checks they do not
result in false matches or missed matches.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Implemented double precision vector fallback for SVE sin/cos.
Includes rewrite of sin to use trig instructions.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Implemented single precision vector fallback for SVE sinf/cosf.
Includes a rewrite of SVE sinf to use the trig instructions.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Implemented single precision vector fallback for AdvSIMD sinf/cosf.
Includes cleanup of the fast pass to remove old styling and conventions.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
_dl_reseed_random zeroed the AT_RANDOM bytes before refilling them with
getrandom (GRND_NONBLOCK). That call is best-effort and can write nothing
(e.g. before the kernel entropy pool is initialized early at boot), leaving
the 16 bytes as a constant zero.
Since the value is exposed through getauxval (AT_RANDOM), this traded a
potential guard leak for a guaranteed predictable value.
Drop the memset and overwrite the bytes in place instead. The generic
version now just drops the pointer (it is not used anywhere).
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Update memchr description to indicate it cannot overread and the size
may be larger than the object passed. This is required since C11.
Suggested-by: Paul Eggert <eggert@cs.ucla.edu>
Reviewed-by: Paul Eggert <eggert@cs.ucla.edu>
Once the pointer and stack guards have been derived from AT_RANDOM, scrub
the bytes and refill them with new random data unrelated to the guards.
On Linux, it uses getrandom syscall (as for tcache_key_initialize), and
fallback to zero the memory if the syscall is not avaiable.
This keeps AT_RANDOM useful to applications while ensuring those bytes no
longer reveal the guards.
The work is done by _dl_reseed_random, called once the guards are in place
and before any ELF constructor can observe AT_RANDOM: in security_init for
the dynamic loader and in __libc_start_main for statically linked programs.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
Reviewed-by: DJ Delorie <dj@redhat.com>
The generic and the Linux _dl_setup_stack_chk_guard and
_dl_setup_pointer_guard are identical when the kernel provides the
AT_RANDOM auxiliary vector, which is always the case on the supported
Linux kernels; the generic version only adds a fallback for a missing
AT_RANDOM. Remove the Linux-specific dl-osinfo.h and use the generic
one for all targets.
The removed header pulled in <dl-sysdep.h>, which is what transitively
declared __libc_enable_secure for dl-parse_auxv.h; include <unistd.h>
there directly so it no longer relies on that. Include <string.h> in
the generic header so it is self-contained.
Reviewed-by: DJ Delorie <dj@redhat.com>
The per-architecture pointer_guard.h files all implemented some variant
of C PTR_MANGLE/PTR_DEMANGLE: the i386 and x86_64 versions did an
exclusive-or by the guard followed by a rotate left by
2 * sizeof (uintptr_t) + 1 bits (9 on 32-bit, 17 on 64-bit), while the
other targets did the exclusive-or only. The assembly macros likewise
rotated on i386 and x86_64 but not on the other targets.
Consolidate everything to use XOR + rotate uniformly: collapse the
per-architecture C headers into a single generic implementation, and
add the matching rotate to the assembly implementations that lacked it.
Targets with an assembly rotate instruction (aarch64, arm, loongarch,
powerpc, s390, csky) just add it. Those without one (alpha, sparc, sh)
synthesize the rotation: alpha and sparc with a shift/shift/or sequence,
which needs an extra scratch register added to the PTR_MANGLE/PTR_DEMANGLE
macros, sh with single-bit rotates, which needs no scratch. The s390
__longjmp and ____longjmp_chk demangle the return address and stack
pointer in C, so update those too.
Checked with setjmp, ptrguard and longjmp_chk tests for all supported
ABIs that can run under qemu (all but csky), and with builds for all
supported ABIs.
Reviewed-by: DJ Delorie <dj@redhat.com>
arc, m68k, microblaze, mips, and riscv store the raw stack pointer in
setjmp, while their jmpbuf-unwind.h applies PTR_DEMANGLE to it in
_jmpbuf_sp. This is currently harmless because these ABIs use the
generic pointer_guard.h, where the C PTR_DEMANGLE is a no-op.
No functional change.
Reviewed-by: DJ Delorie <dj@redhat.com>
Move the assembly PTR_MANGLE/PTR_DEMANGLE definitions out of each
pointer_guard.h into a new sibling pointer_guard-asm.h, guarded by
__ASSEMBLER__. pointer_guard.h now includes pointer_guard-asm.h and
keeps only the C definitions.
No functional change: the .S and .c files still include pointer_guard.h
and get the same macros, and <pointer_guard-asm.h> resolves per-arch
through the usual sysdeps include path.
Checked with a build for all affected ABIs.
Reviewed-by: DJ Delorie <dj@redhat.com>
i386, powerpc, s390, sh and sparc fell back to the generic no-op
pointer_guard.h in ld.so, so the loader's own setjmp/longjmp and mangled
function pointers were left unprotected (the other targets already
mangle in rtld). ld.so is position-independent and sets up
__pointer_chk_guard_local early in dl_main, so the loader can reach it
the same way a statically linked program does:
- powerpc, s390, sh, sparc: select __pointer_chk_guard_local for
IS_IN (rtld) and reuse the existing PIC guard load.
- i386: load it via @GOTOFF off a GOT pointer set up with LOAD_PIC_REG
in the caller-provided scratch register
(ld.so does not keep the GOT in %ebx at the setjmp/longjmp entry).
- s390: drop the IS_IN (rtld) "#undef PTR_DEMANGLE" in __longjmp.c so
the loader's longjmp demangles to match its setjmp.
Checked on x86_64-linux-gnu, aarch64-linux-gnu, i686-linux-gnu, and
armv7a-linux-gnueabihf. I also run elf and setjmp checks on qemu
loongarch64, powerpc64, powerpc64le, and s390x systems.
Reviewed-by: DJ Delorie <dj@redhat.com>
For the targets that still read the pointer guard from the thread
descriptor (i386, x86_64, powerpc, s390, sparc, and sh), mangle and
demangle pointers using the module-local __pointer_chk_guard_local (in
ld.so and static binaries) or the global __pointer_chk_guard provided by
the dynamic loader (in shared objects), matching the scheme already used
by aarch64, alpha, arm, csky and loongarch.
On i386 the guard is no longer reachable as a single %gs-relative memory
operand, so the assembly PTR_MANGLE/PTR_DEMANGLE PIC variants need a
register to hold the GOT pointer and the guard address.
This removes the dependency on the TCB pointer_guard slot: drop
THREAD_{GET,SET,COPY}_POINTER_GUARD and the POINTER_GUARD tcb-offset,
and point the POINTER_CHK_GUARD test macro at the relro variable. The
tcbhead_t slot is kept (renamed to an unused reserved field, except on
s390 which reused the stack guard) to preserve the ABI. s390 gains a
distinct pointer guard rather than aliasing the stack guard.
Checked on x86_64-linux-gnu, aarch64-linux-gnu, i686-linux-gnu, and
armv7a-linux-gnueabihf. I also run elf and setjmp checks on qemu
loongarch64, powerpc64, powerpc64le, and s390x systems.
Reviewed-by: DJ Delorie <dj@redhat.com>
The static-dlopen does not initialize the pointer guard for ABIs that
define THREAD_SET_POINTER_GUARD. Besides not properly guard the
pointer if a libc.so symbol is called, this can lead to setjmp
failures (a jmp_buf set up by the loaded libc.so.6 cannot be restored
by the static program's __longjmp, and vice versa).
Seed the just-mapped loader's __pointer_chk_guard from the program's
__pointer_chk_guard_local in __rtld_static_init, next to the other
runtime values copied there.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
Reviewed-by: DJ Delorie <dj@redhat.com>
It syncs with CORE-MATH commit 887cab6f. The new tests are from
the CORE-MATH acosh worst-cases inputs that trigger the FE_TOWARDZERO
issue with the previous implementation, along with the hard-to-round
cases from CORE-MATH commits 72febed6 and ce9e99f6.
Checked on x86_64-linux-gnu, x86_64-linux-gnu with --disable-multi-arch
(so soft FMA implementation is used), i686-linux-gnu (which uses its
own acosh implementation), aarch64-linux-gnu, and
armv7a-linux-gnueabihf.
Reviewed-by: Paul Zimmermann <Paul.Zimmermann@inria.fr>
The --enable-static-nss configuration adds -DSTATIC_NSS to CFLAGS for
the inet subdirectory, but no source file has referenced the STATIC_NSS
macro for quite some time. So remove the dead define.
Signed-off-by: Michael Ford <fanquake@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
nsswitch.c no longer references any of the *_SO macros provided by
<gnu/lib-names.h>. The only consumer, __nss_shlib_revision, moved to
nss_module.c as part of the NSS reorganization in glibc 2.33 (and
nss_module.c includes the header unconditionally), but the guarded
include was left behind.
Signed-off-by: Michael Ford <fanquake@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
_dl_runtime_resolve and _dl_runtime_profile only preserved the integer
argument registers (r0-r3) across the inner call to _dl_fixup /
_dl_profile_fixup. Two related ABI requirements demand more:
* Under AAPCS-VFP, d0-d7 hold the caller's double arguments to the
function being resolved. Recent GCC emits VFP instructions inside
the fixup routines, clobbering them, so the resolved function sees
corrupted arguments (BZ 34144).
* Per RTABI32, the __aeabi_mem* helpers (and similar runtime helpers
reachable through the dynamic linker) must only corrupt integer
core registers. IFUNC resolvers, audit modules, and interposed
malloc invoked during symbol resolution may also use VFP, even on
softfp ABI builds (BZ 15792).
Save all call-clobbered VFP state -- d0-d15 unconditionally, d16-d31
when HWCAP_ARM_VFPD32 is set, and fpscr -- around the inner fixup
call. Whether VFP is usable is a property of the hardware, not of
the ABI glibc was built with, so the decision is gated on AT_HWCAP at
runtime in both hardfp and softfp builds; hardfp builds will always
find HWCAP_ARM_VFP set, while softfp builds running on a non-VFP CPU
correctly skip the save.
For _dl_runtime_profile the save area is slipped in just before the
bl to _dl_profile_fixup; the outgoing framesizep argument is
recomputed to account for the extra frame, and both the fast path
(no audit framesize) and the slow path (audit wraps with
pltenter/pltexit) traverse the restore before splitting.
Checked on arm-linux-gnueabihf.
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
ARCH_INIT_CPU_FEATURES is called from __libc_start_main before
_dl_relocate_static_pie, so any code it runs must not rely on
relocations being applied yet. Two issues break this under static PIE:
1. The cpu_list table held 'const char *name' members, whose
addresses are not link-time constants under PIE and thus require
base-relative relocations that are not yet in place. Replace the
array of structs with a flat NUL-separated name string and a
parallel midr array, removing the pointer relocations.
2. tunable_strcmp pulls in memcmp, which is an IFUNC and is likewise
unresolved at this point. Redirect memcmp to __memcmp_generic in
the aarch64 dl-symbol-redir-ifunc.h and include it from
csu/libc-start.c.
Checked on aarch64-linux-gnu.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
pthread_setname_np opens the thread's comm file using O_RDWR, but the
function only ever writes to it. This causes two distinct problems:
1. Missing O_CLOEXEC: the file descriptor is not marked close-on-exec,
so it remains open across fork+exec. A child process that audits
its inherited file-descriptor set will encounter an unexpected /proc
fd it did not open and may treat this as a security violation and
abort.
2. Unnecessary O_RDWR: requesting read+write access when only write
access is needed can cause open() to fail under security policies
that permit writing to /proc/<tid>/comm but deny reading it.
Fix both issues by replacing O_RDWR with O_WRONLY|O_CLOEXEC
Similarly, updated pthread_getname_np to use O_CLOEXEC.
Bug-Id: 34192[https://sourceware.org/bugzilla/show_bug.cgi?id=34192]
Signed-off-by: Sana Kazi <Sana.Kazi@bmwtechworks.in>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Introduce ifuncs and resolvers for functions pertinent to the
malloc interface on the AArch64 target: malloc, calloc, free,
realloc, memalign, valloc, pvalloc, posix_memalign, aligned_alloc,
free_sized, free_aligned_sized, malloc_usable_size.
A target can define the USE_MULTIARCH_MALLOC macro. In this case
it must provide alternative aliases for the malloc functions that
point to the ifuncs.
This implementation respects the --disable-multi-arch configure
flag. If multi-arch support is disabled, the generic aliases
are used on aarch64.
This patch contains aarch64-specific resolvers. At this moment they
return core implementations but in the future they can be changed
to support for features, e.g. to handle memory tagging.
dl_init_cacheinfo retrieves various information about cache
sizes, using the cpuid instruction on x86.
Previously, the same cpuid leaves were queried multiple times.
This behavior caused intel_check_word to prominently show up in
profiles of dynamic loader startup on the Intel(R) Xeon(R) Gold 6430.
The big performance impact could not be reproduced on other Intel cpus.
This patch reduces the number of cpuid queries on startup
by caching their results on the stack for reuse when searching for a
different cache size value.
This approach does not change the overall design of
the cache enumeration code (repeated calls to handle_* functions).
The values are cached on the stack instead of globally (e.g.
in the cpu_features global) because they are never needed after
early initialization.
The cache is only active for Intel cpus, because it has not yet
been shown through benchmarks that it meaningfully improves performance
for other processors.
Signed-off-by: Fabian Rast <fabian.rast@tum.de>
Reviewed-by: Sunil K Pandey <skpgkp2@gmail.com>
Building for Hurd with GCC mainline produces an error in pt-block.c
(here MSG_OPTIONS is a macro that may be defined before pt-block.c is
included by another source file):
In file included from ../sysdeps/mach/htl/pt-block-intr.c:6:
../sysdeps/mach/htl/pt-block.c: In function '__pthread_block_intr':
../sysdeps/mach/htl/pt-block.c:49:42: error: use of logical '&&' with constant operand '1024' [-Werror=constant-logical-operand]
49 | if ((MSG_OPTIONS & MACH_RCV_INTERRUPT) && err == MACH_RCV_INTERRUPTED)
| ^~
../sysdeps/mach/htl/pt-block.c:49:42: note: use '&' for bitwise operation
49 | if ((MSG_OPTIONS & MACH_RCV_INTERRUPT) && err == MACH_RCV_INTERRUPTED)
| ^~
| &
Fix this, and a similar error in pt-timedblock.c, with an explicit != 0.
Tested with build-many-glibcs.py (compilers and glibcs builds) for
i686-gnu and x86_64-gnu.
Building for sparc64-linux-gnu with GCC mainline produces a series of
-Werror=constant-logical-operand errors in soft-fp code, relating to
calls to _FP_TO_INT where rsigned is -1 not 0 or 1. Use explicit != 0
in the soft-fp code to avoid these errors.
Tested with build-many-glibcs.py (compilers and glibcs builds) for
sparc64-linux-gnu with GCC mainline.
Building the glibc testsuite with GCC mainline fails with:
In file included from tst-printf-format-skeleton-double.c:33,
from tst-printf-format-p-double.c:20:
tst-printf-format-skeleton.c: In function 'do_test':
tst-printf-format-skeleton.c:308:12: error: use of logical '&&' with constant operand '53' [-Werror=constant-logical-operand]
308 | if (PREC && printf ("prec:%i\n", PREC) < 0)
| ^~
tst-printf-format-skeleton.c:308:12: note: use '&' for bitwise operation
308 | if (PREC && printf ("prec:%i\n", PREC) < 0)
| ^~
| &
cc1: all warnings being treated as errors
Fix this using an explicit "!= 0". Tested with build-many-glibcs.py
for aarch64-linux-gnu.
Commit 2efc702628 replaces the generic RISC-V memcmp, which also exports
__memcmpeq.
A dedicated RISC-V __memcmpeq implementation is expected in a later patch,
which is still under review. Keep the alias here so this patch does not
temporarily drop the existing __memcmpeq ABI.
Tested on a Muse-Pi board with GCC 15.2.0 using `--with-arch=rv64g_zca_zcd --with-abi=lp64d`
and `CFLAGS="-march=rv64g_zca_zcd -mabi=lp64d -O2"`. Full make check was
run for both multiarch and non-multiarch builds.
This also fixes the string/inl-tester link failure caused by the missing
__memcmpeq symbol.
In both runs, the only FAILs are the unchanged cospi/sinpi/tanpi math test
failures.
Signed-off-by: Zihong Yao <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
When tentatively converting characters on behalf of
__gconv_transliterate, do not create a persistent error. Just
produce a local error, and rely on __gconv_transliterate to
produce the error if all transliteration options are exhausted.
This fixes transliteration of “½” to ASCII, which cannot use the
“ 1⁄2 ” alternative. Eventually, the “ 1/2 ” alternative is chosen,
but the error sticks. Therefore, iconv exited with status 1 before
this change.
Adjust iconv/tst-iconv_prog.sh to test both C and en_US.UTF-8 locales.
This requires changing the way the ICONV template is defined, so that
run_program_env is evaluated multiple times.
Fixes commit 9a4b0eaf72 ("iconv: do not
report error exit with transliteration [BZ #32448]"),
commit 6cbf845fcd ("iconv: Preserve
iconv -c error exit on invalid inputs (bug 32046)"), and bug 34236.
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
With 01964c3ec8e fix ifunc resolvers can be fully instrumented with
stack protector.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu
built with --enable-stack-protector=all.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
An IFUNC resolver in a DSO that is being loaded by dlopen is allowed
to read its own TLS storage during the resolver call. After
af34b1376a ("elf: Initialize static TLS before relocation processing
(BZ 34164)") that works for the initial-exec model on every supported
architecture.
However, it does not work for the dynamic-TLS path (on both -mtls-dialect mode,
if the ABI supports both). Both lookup paths index the calling thread's
DTV by the new module's l_tls_modid and, on miss, walk
GL(dl_tls_dtv_slotinfo_list) to discover the module and lazily allocate
its TLS block. The just-loaded DSO is however not yet in that list when
its resolver fires, so the lookup faults inside dlopen. This is the
direct dlopen analog of BZ 34164.
The solution is to reorder dl_open_worker_begin so the slotinfo install
happens before the relocation pass. The new order is:
1. resize_scopes, resize_tls_slotinfo, add_to_global_resize
(unchanged, still recoverable).
2. update_tls_slotinfo: register the new modules in slotinfo, bump
dl_tls_generation, initialise their static TLS images.
3. Relocate the new objects. IFUNC resolvers can now read their
own DSO's __thread storage via any TLS model.
4. Demarcation point.
5. update_scopes, _dl_find_object_update.
Checked on aarch64-linux-gnu and x86_64-linux-gnu.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Simplify _int_free_chunk() and always lock if needed. Use
_int_free_merge_chunk() for cases that assume the arena has been locked
instead. Move the errno save/restore to _int_free_maybe_trim().
Reviewed-by: Yury Khrustalev <yury.khrustalev@arm.com>
This patch adds an RVV-optimized implementation of strrchr for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__strrchr_vector) is added
alongside the generic fallback (__strrchr_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling strrchr().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
This patch adds an RVV-optimized implementation of strchr for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__strchr_vector) is added
alongside the generic fallback (__strchr_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling strchr().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
This patch adds an RVV-optimized implementation of memchr for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__memchr_vector) is added
alongside the generic fallback (__memchr_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling memchr().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
This patch adds an RVV-optimized implementation of memccpy for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__memccpy_vector) is added
alongside the generic fallback (__memccpy_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling memccpy().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
This patch adds an RVV-optimized implementation of memcmp for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__memcmp_vector) is added
alongside the generic fallback (__memcmp_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling memcmp().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
The default maximum arenas is 8 times the number of cores in a 64-bit system.
Since modern CPUs have many cores and big servers have 256 cores, this results
in excessive number of arenas, which wastes memory. Limit the number of arenas
to max (8, ncores) which is less extreme. In the future the limit should be
lowered further for large systems.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
__res_iclose, when called with FREE_ADDR=true, frees and NULLs every
statp->_u._ext.nsaddrs[ns] but does not reset statp->_u._ext.nscount.
This breaks the invariant relied on by __res_context_send's cache
validation loop in resolv/res_send.c:293-312: when _u._ext.nscount
is non-zero, every _u._ext.nsaddrs[ns] corresponding to
statp->nsaddr_list[ns].sin_family != 0 is expected to be non-NULL.
res_init unconditionally calls __res_iclose(&_res, true) before
__res_vinit, so any __res_vinit failure (for example,
fopen("/etc/resolv.conf") returning EMFILE under file-descriptor
exhaustion, or any allocation failure in __resolv_conf_load,
__resolv_conf_allocate, or __resolv_conf_attach before
update_from_conf runs) leaves _u._ext.nscount non-zero with all
_u._ext.nsaddrs[] NULL. The next name lookup walks the validation
loop and dereferences NULL in sock_eq. A DNS lookup may fail after
a failed res_init, but it should not segfault.
Reset _u._ext.nscount = 0 alongside the existing __resolv_conf_detach
call. The next __res_context_send call then re-enters its init
block (res_send.c:316-335) and repopulates _u._ext.nsaddrs[] from
statp->nsaddr_list[], which __res_iclose leaves untouched. This
also lets support/resolv_test.c drop its now-redundant manual reset
after __res_iclose(&_res, true).
Add a regression test that drops RLIMIT_NOFILE so fopen of
/etc/resolv.conf fails with EMFILE inside __res_vinit, then verifies
the subsequent gethostbyname does not crash.
Signed-off-by: Adam Yi <ayi@janestreet.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Update default for tcache_count tunable. Remove existing documentation and
mention removal of fastbins in mxfast tunable. Improve wording of hugetlb
tunable, including default for AArch64.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Merge request2size into checked_request2size. Improve interface of
clear_memory. Fix incorrect use of __glibc_unlikely in __libc_calloc.
Fix missing tabs.
Reviewed-by: Yury Khrustalev <yury.khrustalev@arm.com>
The glibc.malloc.hugetlb=1 is redundant with kernel is n 'always'
mode, but the madvise does work, and the tunable should not fail.
Suggested-by: Yury Khrustalev <yury.khrustalev@arm.com>
Reviewed-by: Yury Khrustalev <yury.khrustalev@arm.com>
Commit c2d6afb4a0 changed the PIC && !SHARED path of start.S (used by
crt1.o and rcrt1.o) to load main via a R_ARM_REL32 data relocation. When
main is provided by a shared object, BFD ld synthesizes a canonical PLT
entry for it, but other linkers (e.g. mold) do not, producing a broken
binary that crashes at startup.
Follow the aarch64 approach and reference main through a local __wrap_main
that tail-calls it with a branch relocation, which every linker turns into
a PLT entry.
Checked on armv7a-linux-gnueabihf with and without --enable-default-pie.
The test failed with --disable-default-pie because its primary check read
the resolver's diagnostic side effect before the resolver had run.
In a non-PIE executable the references to the IFUNC (fptr and ifunc_tls)
are satisfied through a canonical IPLT entry in the executable itself.
Under the default lazy binding that IPLT is resolved on first use, not
during startup relocation, so the resolver had not yet run when
'check_sentinel' inspected that value. With a PIE executable
(or LD_BIND_NOW=1) the resolver runs eagerly at startup and the check
passed. The dlopen path was unaffected because dlopen resolves the
data relocation eagerly.
This is a test ordering issue: the resolver always reads the initial-exec
TLS correctly whenever it runs, so the BZ 34164 fix is not involved.
Reorder test_tls_ifunc so that fptr/ifunc_tls force the IFUNC to be
resolved before the last_seen_sentinel value is inspected.
Checked on x86_64-linux-gnu and i686-linux-gnu with --disable-default-pie.
Reported-by: Yury Khrustalev <yury.khrustalev@arm.com>
Reviewed-by: Yury Khrustalev <yury.khrustalev@arm.com>
__memcmpeq (added in glibc 2.35) was previously an alias to memcmp on
POWER10 via strong_alias. However, in the multiarch IFUNC path, this
caused __memcmpeq to resolve to the generic C memcmp.c implementation
rather than the optimized POWER10 memcmp.S, leaving a significant
performance gap.
Unlike memcmp, __memcmpeq only needs to return zero or nonzero with
no requirement on the sign or magnitude for unequal inputs, allowing
a simpler and faster implementation.
Performance on POWER10 :
1) __memcmpeq (generic) -> __memcmpeq_power10
The primary motivation - __memcmpeq was resolving to generic C
in the multiarch path.
- Small data (< 8B to < 512B) : ~52% - 82% improvement.
- Bulk (< 16MB to < 256MB) : ~25% - 32% improvement.
- Large (1GB) : ~33% improvement
2) memcmp_power10 (optimized .S) -> __memcmpeq_power10:
Comparing dedicated __memcmpeq against the optimized memcmp
it previously aliased to.
- Small data (< 8B to < 256B) : No improvement observed.
Real-world workloads predominantly operate on larger buffers
- >= 512B : ~9% improvement.
- 16MB - 128MB : ~25% - 32% improvement.
- 256MB : ~3% improvement.
- Large (1GB) : On par.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
After "elf: Initialize TCB and stack-protector before static IFUNC
resolvers (BZ 20680, BZ 27582, BZ 28817)", early loader and static
initialization code may run before the IFUNC resolvers are processed.
The armv7-a supports memcpy, so add a dl-symbol-redir-ifunc.h to
redirect the memcpy to to __memcpy_arm implementation.
Checked on armv7a-linux-gnueabihf.
Remove the --enable-memory-tagging configure option along with
all associated variables and macros.
Removing the glibc.mem.tagging tunable.
Remove the memory-tagging makefile variable.
Remove the USE_MTAG macro definition and code that is conditionally
compiled when this macro is defined.
As a result, we change 'mtag_mmap_flags' to 'extra_mmap_prot' that
is now always defined. Change of the name due to this being used
as part of PROT options in mmap syscalls rather than part of flags.
Remove 'mtag_enabled' that would become compile-time false. Also
remove any code that would never be compiled when 'mtag_enabled'
is false.
Remove AArch64-specific code pertinent to memory tagging, that is
currently broken, from the core malloc implementation. We keep
the assembly code, since we are going to need it in the future. to
preserve Git history.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
The swallow argument in the INT_FIELD and STRING_FIELD macros is used as a
boolean, change all callers to use false and true instead of 0 and 1.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
auto-libm-test-in shares inputs between narrowing and non-narrowing
functions, and some carry arg-format conditions (e.g. "arg-ibm128").
When auto-libm-test-out-fma is regenerated, gen-libm-test.py turns these
into TEST_COND_arg_ibm128, which expands via ARG_MANT_DIG to ARG_PREFIX.
ARG_PREFIX is only defined for TEST_NARROW, so the non-narrowing fma test
failed to build with "ARG_PREFIX_MANT_DIG undeclared".
Define TEST_COND_arg_ibm128 to 0 when ARG_FLOAT is not defined, mirroring
the existing guard for TEST_COND_ibm128_libgcc; in the non-narrowing case
there is no separate argument format, so the condition is always false.
Regenerate auto-libm-test-out-fma accordingly.
When the compiler defines __ARM_BUILDATTR64_FV, emit AArch64
feature-and-bits build attributes for BTI, PAC, and GCS from sysdep.h
instead of a GNU property note. Keep the GNU property note as the
fallback for older toolchains.
Mirror the same marking logic in elf/tst-asm-helper.h so custom test
DSOs and assembly tests that cannot include sysdep.h get consistent
feature marking.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Add a simple test that runs in a UTS namespace: checks gethostname
after various sethostname values (including empty and HOST_NAME_MAX),
verifies ENAMETOOLONG when the buffer is too small for a maximal name,
EINVAL when sethostname is given a name longer than HOST_NAME_MAX.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The test tst-wcsmbs-clone-overflow was initially added to tests-static.
However, this causes the test to be unstable because gconv modules
dynamically load libc.so. Any discrepancy between the statically linked
version and the dynamically loaded one can lead to a crash.
By removing the test from tests-static, it relies on dynamic linking,
safely bypassing the dlopen crash. Since the test is now dynamically
linked, it cannot use the internal thread-local symbol
_NL_CURRENT_DATA(LC_CTYPE) because _nl_current_LC_CTYPE is hidden in
libc.so, leading to undefined references. Thus, the test now uses
newlocale and uselocale, safely extracting the locale data from the
returned locale_t object.
Furthermore, using newlocale requires the gconv-modules configuration to
be built and available so that the ISO8859-1.so module can be
dynamically loaded. Otherwise, glibc falls back to the built-in C locale
conversions, leaving __shlib_handle as NULL and silently bypassing the
reference counter increment.
A new Makefile fragment, gen-gconv-modules.mk, is introduced to ensure
the gconv-modules are built before the test runs, and an explicit check
for __shlib_handle != NULL is added to the test.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
When d (the exponent difference between z and x*y) is exactly 64,
the alignment path shifts z left by 64 bits via (zhi = nz.m, zlo = 0)
and decrements d to 0, then takes the inner 'if (d < 64)' branch
which evaluates 'rhi << (64 - d)' with d == 0. A shift by 64 of a
64-bit value is UB in C.
Add the explicit 'if (d == 0)' empty branch (present in the
original musl implementation).
Checked on x86_64-linux-gnu with --disable-multi-arch and
arm-linux-gnueabihf.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The malloc test variants run with GLIBC_TUNABLES=glibc.malloc.hugetlb=1
exercise transparent huge pages via MADV_HUGEPAGE, which is only
meaningful when /sys/kernel/mm/transparent_hugepage/enabled is set to
'madvise' ('always' makes the madvise redundant and 'never' makes it
ineffective). The hugetlb=2 variants rely on MAP_HUGETLB, which
requires a positive /proc/sys/vm/nr_hugepages. On systems that do not
satisfy these prerequisites - including any non-Linux target - those
runs only consume CPU time in this case.
Add support/support_check_hugetlb.{c,h} exposing:
- support_thp_is_madvise: true iff THP is in 'madvise' mode;
- support_hugepages_reserved: true iff nr_hugepages > 0;
- support_check_malloc_hugetlb: inspects GLIBC_TUNABLES and calls
FAIL_UNSUPPORTED when the requested hugetlb mode cannot be honored.
Gate the check at compile time so only the variant binaries pay for
it.
Reviewed-by: DJ Delorie <dj@redhat.com>
The af34b1376a (BZ 34164) changed the
TLS setup from:
relocation loop (applies relocations to .tdata in DSO memory)
_dl_allocate_tls_init copies relocated .tdata -> main thread TLS
to a new order:
_dl_allocate_tls_init copies unrelocated .tdata -> main thread TLS
relocation loop (relocates .tdata in DSO memory, but the TLS block
has stale copies)
This broke file-scope thread-local initialised with the address of a
function (for instance the cache structs in libmpfr).
Fix it by splitting ELF_DYNAMIC_RELOCATE inside
_dl_relocate_object_no_relro into the non-IRELATIVE and IRELATIVE
sub-passes (similar as done on static-pie startup by b75ad99d45)
and call _dl_init_static_tls between them. By the time the IFUNC
pass fires, .tdata is fully relocated.
Checked on x86_64-linux-gnu and aarch64-linux-gnu.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
This commit splits and sorts the tests in sunrpc/Makefile.
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
We do not define struct ifreq_short and ifreq_int, but we do
define _IOT_ifreq_short and _IOT_ifreq_int, and need these for
sysdeps/gnu/ifaddrs.c and sysdeps/mach/hurd/if_index.c
The s390 specific Makefiles were adjusted to match the required format
for scripts/lint-makefiles.sh / scripts/sort-makefile-lines.py.
Afterwards the lines were sorted by those scripts.
And the testcase lint-makefiles is passing.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Check for task_max_priority RPC
* config.h.in: add #undef for HAVE_MACH_TASK_MAX_PRIORITY.
* sysdeps/mach/configure.ac: use mach_RPC_CHECK to check for
task_max_priority RPC in mach_host.defs.
* sysdeps/mach/configure: regenerate file.
Use task_max_priority when setpriority is called by root
* sysdeps/mach/hurd/setpriority.c: clamp the prio argument
to the range [-NZERO, NZERO-1] and use task_max_priority
when called by root.
Message-ID: <8e806c83d8d7b59b2894b4944e4ad82477ecc3cd.1779316637.git.dnietoc@gmail.com>
POSIX specs specify that invalid flags shall return EINVAL and that
ENOMEM shall be returned in case of address outside of address space or
when one or more pages are not mapped.
Signed-off-by: Etienne Brateau <etienne.brateau@gmail.com>
Message-ID: <20260525211142.131508-1-etienne.brateau@gmail.com>
The Open Group Base Specifications Issue 8
getpriority ( https://pubs.opengroup.org/onlinepubs/9799919799/ )
<< The nice value is in the range [0,2*{NZERO} -1], while the
return value for getpriority() and the third parameter for
setpriority() are in the range [-{NZERO},{NZERO} -1]. >>
So given that NZERO is defined to 20, we shall use it to clamp to the range
specified by POSIX.
That range is then mapped to something similar to [0, 2*{NZERO}-1], as
specified by POSIX, through the usage of the macro NICE_TO_MACH_PRIORITY
and MACH_PRIORITY_TO_NICE. (i.e. [5, 45] )
The final block of tst-gettext unsets LC_ALL plus LC_MESSAGES, LC_CTYPE,
LC_TIME and LC_NUMERIC, sets LANG=existing-locale, and then expects
setlocale (LC_ALL, "") to resolve every category through LANG. Any
other LC_* category inherited from the invoking shell (e.g. LC_PAPER,
LC_MONETARY) still takes precedence over LANG, and if it points to a
locale that is not under the test's LOCPATH the setlocale call fails
with ENOENT.
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The test previously failed with confusing diagnostics in two situations
that are properties of the runtime environment rather than of glibc:
1. find_gdb only checked access(X_OK), which is true for directories
too. A 'gdb' directory ahead of /usr/bin in PATH (e.g. one holding
gdb python helpers) was therefore returned as the gdb executable,
and the subsequent execl failed with errno != ENOENT, causing the
test to fail with `numeric comparison failure ... status 256'.
2. The in-tree libthread_db.so.1 is built with -z mark-plt and
therefore carries a versioned dependency on
GLIBC_ABI_DT_X86_64_PLT in libc.so (see BZ #33212). When the
system gdb is linked against a libc older than 2.41, that version
is not provided and gdb's dlopen of the in-tree libthread_db.so.1
fails. Thread debugging is then disabled, the gdb script's
`thread 1' / `thread 2' commands fail, gdb exits non-zero, and the
test reports a generic status mismatch.
Two changes:
* Require S_ISREG in find_gdb so a directory named 'gdb' on PATH is
skipped, falling through to the next candidate.
* Before running the real gdb scenario, run a minimal probe script
that triggers libthread_db loading (set debug libthread-db 1; set
libthread-db-search-path; file /proc/self/exe; start). If the
probe output contains `dlopen failed', mark the test UNSUPPORTED
with a clear message instead of letting the real run fail.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Old alpha glibc defined rlim_t as signed long, making RLIM_INFINITY
equal to LONG_MAX (0x7ffffffffffffffful). The compat symbol
__old_setrlimit64 (setrlimit@GLIBC_2.0 and setrlimit64@GLIBC_2.1) was
introduced in 0d0bc784ca [BZ #22648] to translate this old RLIM_INFINITY
to the kernel's RLIM64_INFINITY (ULONG_MAX) before the prlimit64
syscall, using an exact equality check.
Because old rlim_t was signed, any value a caller treats as negative
(e.g. -2 = 0xfffffffffffffffe unsigned) is also an "infinity or beyond"
value in the old ABI. Such values are >= OLD_RLIM64_INFINITY and
should be translated to RLIM64_INFINITY; passing them through unchanged
causes prlimit64 to treat them as large finite limits, resulting in
unexpected failures (EPERM or silent truncation).
Change the equality check to >= OLD_RLIM64_INFINITY in
__old_setrlimit64 so that all values the old signed-rlim_t ABI would
interpret as infinity-or-more are correctly mapped to RLIM64_INFINITY.
No change is made to __old_getrlimit64: prlimit64 returns only exact
RLIM64_INFINITY for unlimited resources, so the existing equality
check against RLIM64_INFINITY is correct and mirrors the kernel's own
rlim64_is_infinity() logic.
Fixes: 0d0bc784ca ("Alpha: Add wrappers to get/setrlimit64 to fix
RLIM64_INFINITY constant [BZ #22648]")
Fixes: https://sourceware.org/bugzilla/show_bug.cgi?id=30992
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
r3 is caller-saved. When a function call appears in the args list
(e.g. INTERNAL_SYSCALL_CALL(tgkill, __getpid(), tid, sig)),
SUBSTITUTE_ARGS evaluates __getpid() before r3 is reloaded, leaving
r3=20 (__NR_getpid) instead of __NR_tgkill=270. The trapa then
dispatches the wrong syscall and the signal is silently dropped.
Fix: declare r3 uninitialised, expand SUBSTITUTE_ARGS (all function
calls happen here), then assign the syscall number to r3 with no
intervening calls before the trapa. Applies to both INTERNAL_SYSCALL
and INTERNAL_SYSCALL_NCS.
signal/tst-raise is a regression test for this bug: raise() calls
tgkill(__getpid(), tid, sig), which triggers the clobber.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
In static linking the IFUNC IPLT (apply_irel for non-PIE, the IRELATIVE
phase inside _dl_relocate_static_pie for static-pie) ran before
__libc_setup_tls and before _dl_setup_stack_chk_guard. When a resolver
is compiled with -fstack-protector(-all) its prologue loads the canary
from the TCB (TCB-canary ABIs: x86_64, i386, powerpc, s390) or from
__stack_chk_guard (global-var ABIs). On the former the resolver
crashed reading an unmapped TCB; on the latter it loaded a zero canary
(no crash, but the check is ineffective). The same applies to a
resolver that reads any thread-local: it crashes on TCB-canary ABIs and
observes a zero-filled slot on the others (BZ 20680). The pointer
guard has the same problem (e.g. resolvers that register an atexit
handler).
Reorder csu/libc-start.c so that ARCH_SETUP_TLS, the stack-protector
canary and the pointer guard are set up before any IFUNC resolver
runs. For static-pie this requires splitting the existing
_dl_relocate_static_pie into two phases so the TCB/canary setup can be
interleaved between the non-IRELATIVE and IRELATIVE passes.
The historical ARCH_SETUP_IREL / ARCH_APPLY_IREL split (introduced for
powerpc so its IFUNC resolvers could read TCB fields like hwcap and
at_platform) is no longer required: TLS is now set up before either
macro runs. ARCH_APPLY_IREL is removed, ARCH_SETUP_IREL does the work
uniformly on every arch, and the powerpc-specific libc-start.h becomes
redundant.
__libc_setup_tls reaches memcpy / mempcpy via _dl_allocate_tls_init in
elf/dl-tls.c, so it requires update ABI specific dl-symbol-redir-ifunc.h
with memcpy/memmove.
Tests added (each fails pre-fix on TCB-canary ABIs with SIGSEGV; the
static-protector variants additionally fail on global-var ABIs with a
"resolver_canary != main_canary" diagnostic):
elf/tst-ifunc-bz28817 static-pie + TLS in
resolver (BZ 28817)
elf/tst-ifunc-resolver-protector dynamic
elf/tst-ifunc-resolver-protector-static static-pie
elf/tst-ifunc-resolver-protector-static-non-pie non-PIE static
Checked on aarch64-linux-gnu, arm-linux-gnueabihf, x86_64-linux-gnu,
and i686-linux-gnu
I also ran the ELF tests on qemu system for loongarch64-linux-gnuf64,
powerpc-linux-gnu, powerpc-linux-gnu-power4, powerpc-linux-gnu-soft,
powerpc64-linux-gnu, powerpc64le-linux-gnu, riscv64-linux-gnu, and
s390x-linux-gnu.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
An IFUNC resolver firing during dynamic linker relocation reads its
DSO's __thread storage from a zero-filled slot: init_tls() allocates
the static TLS block zero-filled, but .tdata is not copied in until
the trailing _dl_allocate_tls_init at the end of dl_main, long after
the per-object phase 2 resolvers from commit 63b31c05a8 have run.
A resolver that *writes* TLS is even worse off -- the write is
clobbered by that same trailing copy.
dl_main (elf/rtld.c): populate the DTV slotinfo, bump
dl_tls_generation, and call _dl_allocate_tls_init right after
init_tls(), before the relocation loop.
_dl_try_allocate_static_tls (elf/dl-reloc.c): drop the
"defer-if-not-relocated" branch and always run _dl_init_static_tls
inline, so a CHECK_STATIC_TLS allocation triggered mid-relocation
initialises the slot before the same object's phase 2 fires.
The new tests cheks some scenarios:
elf/tst-ifunc-tls-init resolver reads its DSO's IE TLS.
elf/tst-ifunc-tls-init-dlopen same, via dlopen.
elf/tst-ifunc-tls-write resolver write to TLS must survive
to main.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The tests for memchr attempt to check for accidental overreads that cross a
page. However they weren't done at the end of a page and don't check for the
case where we match right at the end. Add buf1_size/buf2_size to make finding
end of buffer easier.
Reviewed-by: Yury Khrustalev <yury.khrustalev@arm.com>
This patch adds vectorised special cases for the SVE log functions
log1p and log1pf.
When built with GCC-15 and executed on a Neoverse V2 platform, the
following benchmarking throughput uplifts were measured:
log1pf -> 285% speed-up (4.85 ns/element to 1.26 ns/element)
log1p -> 117% speed-up (8.25 ns/element to 3.80 ns/element)
Note that the numbers here are for the special case path only and that
the fast path performance has been maintained. These changes have also
maintained the same level of accuracy as before.
* stdio-common/vfscanf-internal.c: If user explicitly set the maximum
size of the string, respect it when reading characters. Instead of
always expanding exponentially, try to expand array to the exact size
user requested when `user_size < current_size * 2`.
Signed-off-by: Rocket Ma <marocketbd@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch adds vectorised special cases for the SVE inverse hyperbolic
functions atanh, acosh and asinh for single precision floats. It also
moves the commonly used inf and nan bit values into the sv_log1pf_inline
data struct for resuse.
When built with GCC-15 and executed on a Neoverse V2 platform, the
following benchmarking throughput uplifts were measured:
atanh -> 215% speed-up (5.51 ns/element to 1.75 ns/element)
acosh -> 152% speed-up (4.63 ns/element to 1.84 ns/element)
asinh -> 51% speed-up (5.00 ns/element to 3.31 ns/element)
Note that the numbers here are for the special case path only and that
the fast path performance has been maintained.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
On AMD Zen 3/4/5 with ERMS, the non-temporal memset path is unreachable
because rep_stosb_threshold is set to SIZE_MAX (vectorized loop is faster
than ERMS on these CPUs), but the non-temporal code path is nested inside
the rep_stosb branch.
The existing rescue logic at the Avoid_STOSB check only covers the case
where the CPU lacks ERMS hardware support. It does not cover AMD Zen 3+
where ERMS is supported but deliberately unused for performance reasons.
Extend the condition to also lower rep_stosb_threshold when:
- The user has not explicitly set x86_rep_stosb_threshold (respect tunables)
- rep_stosb_threshold is higher than memset_non_temporal_threshold (NT gated)
This makes the non-temporal path reachable for large memset operations,
providing ~2x speedup on pre-faulted buffers larger than L3 cache.
Tested on AMD Ryzen 7 8745HS (Zen 4):
- Pre-faulted 64MB memset: 2.02 ms -> 0.94 ms (2.15x faster)
- First-touch 64MB memset: 19.3 ms -> 21.3 ms (11% regression, expected:
kernel clear_page cache warming bypassed by NT stores)
* sysdeps/x86/dl-cacheinfo.h (dl_init_cacheinfo): Extend
rep_stosb_threshold lowering condition to cover AMD Zen 3/4/5
where ERMS is supported but stosb is disabled via threshold.
Signed-off-by: zombie12138 <zombie12139@gmail.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34129
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
setvbuf (stream, NULL, _IOFBF, 0) takes a special path in
_IO_setvbuf: if the byte-oriented buffer base is NULL, it calls
_IO_DOALLOCATE and returns without invoking the stream setbuf hook.
For open_wmemstream, the byte-oriented buffer base is NULL although
the wide result buffer has already been initialized in _wide_data.
As a result, this path calls _IO_wdefault_doallocate, which may
replace the wide buffer managed by open_wmemstream.
Install an open_wmemstream-specific doallocate hook that leaves
the growable result buffer unchanged. Add a regression test for this
path.
Install a narrow memstream doallocate hook as well. It keeps both
memstream vtables consistent (generic stdio allocation must not
replace the growable result buffer).
Signed-off-by: Xiang Gao <gaoxiang@kylinos.cn>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
open_memstream and open_wmemstream manage an internal growable buffer.
The default setbuf hook can reset that buffer, breaking the assumptions
used by the string stream overflow paths.
Install setbuf hooks that leave the internal buffer unchanged, and add
regression test cases for the narrow and wide cases, based on the
reproducer in BZ #34019.
Checked on x86_64 with no regression in the libio tests.
Reported-by: Rocket Ma <marocketbd@gmail.com>
Signed-off-by: Xiang Gao <gaoxiang@kylinos.cn>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Benchmarks on Hygon processors show that the default non-temporal
threshold is higher than ideal for large copy workloads. As a result,
memcpy and memmove may continue to use the temporal copy path for
longer than is beneficial, increasing cache pollution and reducing
throughput for large copies.
Lower the copy non-temporal threshold to 3/8 of the shared cache size
per thread on Hygon. This allows the non-temporal copy path to be
selected earlier while leaving the memset non-temporal threshold
unchanged.
Signed-off-by: xiejiamei <xiejiamei@hygon.cn>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
If a shared library's constructor calls dlsym and discards the result,
the compiler is free to lower the call to a tail jump. The dynamic
linker then resolves the apparent caller to ld.so's own link map, which
has no l_scope, and crashes in _dl_lookup_symbol_x dereferencing the
NULL scope pointer.
Tail-call optimization is a legal C transformation and there is no way
for the dynamic linker to recover the real caller from the elided frame.
Detect the situation by its observable effect -- a link map with no
l_scope -- and fall back to the main program's link map, the same
treatment used when the caller's address is otherwise unrecognized.
The check is written against l->l_scope rather than against _dl_rtld_map
directly because dl-sym-post.h is also compiled into libc.so, where
_dl_rtld_map is not visible (it lives only in ld.so).
Add dlfcn/tst-dlsym-ctor exercising the pattern. Without the fix the
test SIGSEGVs during dlopen; with the fix dlopen returns cleanly.
Signed-off-by: Daan De Meyer <daan@amutable.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Update the gettext section to reflect the 2026 sync with GNU
gettext 1.0 (through commit 2ebbdd0e2). Add intl/eval-plural.h
which was missing from the shared files list.
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
In _nl_find_msg (dcigettext.c), outbuf was computed as
freemem + sizeof(size_t) before checking whether freemem_size is
large enough. When freemem is NULL (initial state), this is
undefined behaviour i.e arithmetic on a null pointer. Move the
outbuf assignment after the size check where freemem is guaranteed
to be a valid allocation.
In read_alias_file (localealias.c), after realloc the old
string_space pointer is dangling. The expression
new_pool - string_space subtracts a valid pointer from a dangling
one, which is undefined behaviour per ISO C 23.
Rewrite as new_pool + (map[i].alias - string_space) so both
operands of the subtraction point into the same (old) object
before string_space is reassigned.
Based on GNU gettext commits 695429040 and 2ebbdd0e2.
Original author: Bruno Haible <bruno@clisp.org>
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Hurd bootstrap with build-many-glibc.py fails for i686-gnu since
4c6f92daea:
In file included from zic.c:16:
private.h:849:1: error: static declaration of ‘mempcpy’ follows non-static declaration
849 | mempcpy(void *restrict s1, void const *restrict s2, size_t n)
| ^~~~~~~
In file included from ../include/string.h:60,
from private.h:222:
../string/string.h:432:14: note: previous declaration of ‘mempcpy’ with type [...]
432 | extern void *mempcpy (void *__restrict __dest,
| ^~~~~~~
The libc-symbols.h already defined some HAVE_*, but timezone files are
built with -D_ISOMAC. Remove its usage and only define _ and N_
macros if not already defined.
Checked on x86_64-linux-gnu and with a build-many-glibcs.py build for
i686-gnu.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Paul Eggert <eggert@cs.ucla.edu>
_dl_init_paths used strdupa to make a mutable copy of LD_LIBRARY_PATH
for fillin_rpath to tokenize. The env block is attacker-controllable
and Linux allows individual variables up to MAX_ARG_STRLEN (32 *
PAGE_SIZE = 128 KB), so the strdupa can push tens of KB onto the
loader's startup stack on top of the env block that already sits on
the initial stack. With a reduced RLIMIT_STACK the doubled copy
overflows before main () is reached.
Replace the strdupa with a dl_scratch_buffer: short paths stay in
the 256-byte inline area, longer ones spill to anonymous mmap (malloc
is not yet available during _dl_init_paths). Two follow-on changes
make the new scratch lifetime safe against _dl_signal_error:
* Count entries directly off the const LD_LIBRARY_PATH and allocate
__rtld_env_path_list.dirs *before* the scratch is live. That way
the larger of the two heap allocations the loader controls signals
its OOM with no scratch to leak.
* Convert fillin_rpath to return bool instead of calling
_dl_signal_error internally on per-entry malloc failure. Its
only caller in the LLP path now frees the scratch first and then
signals the error from a clean state. decompose_rpath, the other
caller, is updated symmetrically. This also fixes a pre-existing
leak in fillin_rpath's OOM path, where the to_free heap copy from
expand_dynamic_string_token was not released before the
_dl_signal_error.
Checked on x86_64-linux-gnu, aarch64-linux-gnu, and i686-linux-gnu.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The expand_dst macro in _dl_map_object_deps performs an unbounded
alloca via DL_DST_REQUIRED, which scales with the link map's
l_origin length plus the count of dynamic-string tokens in the
input string. When a DT_NEEDED entry carries several DSTs and the
link map sits in a deep directory, the resulting allocation grows
to several kilobytes -- enough to overflow a PTHREAD_STACK_MIN
thread that calls dlopen.
Convert the macro to a static function that draws from a caller-
owned dl_scratch_buffer, so oversized expansions land on the heap
(or anonymous mmap during early startup) instead of the stack.
The scratch buffer is reused across DT_NEEDED, DT_AUXILIARY, and
DT_FILTER entries of the same map and freed once dependency
expansion completes.
A new regression test, tst-dst-needed-minstack, builds a wrapper
library that inherits a five-DST SONAME from a leaf module,
deploys it under a deep temporary directory, and dlopens it from
a PTHREAD_STACK_MIN thread. Without the fix the dlopen overflows
the thread stack and crashes; with the fix the dlopen returns
cleanly (with or without a successful load).
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The alloca added by commit ccdb048d ("Fix recursive dlopen") to
snapshot the matched cache entry before __strdup runs through
interposable malloc is sized by best_len, which can reach PATH_MAX.
On PTHREAD_STACK_MIN threads that's enough to overflow the stack
mid-dlopen.
Use dl_scratch_buffer with DL_SCRATCH_NO_MALLOC: short entries stay
in the 256-byte inline area, longer ones spill to anonymous mmap
rather than to interposable malloc. The recursive-dlopen invariant
is preserved.
New container test elf/tst-dl-cache-long-path constructs a ~3.4 KB
deep directory, populates ld.so.cache with that entry, and dlopens
from a PTHREAD_STACK_MIN thread under deliberate stack pressure;
reliably SIGSEGVs against the alloca-based code and passes with the
fix.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
is_trusted_path_normalize, print_search_path, and open_path used
alloca or a VLA to hold a path scratch buffer sized by user-controlled
inputs (an RPATH directory length, or
max_dirnamelen + max_capstrlen + namelen). On the worst case that
consumes up to PATH_MAX bytes of stack per call, which can overflow a
PTHREAD_STACK_MIN-sized stack mid-dlopen when combined with the
loader's other on-stack scratch (struct filebuf, etc.).
Replace those allocations with dl_scratch_buffer. As a small cleanup,
print_search_path now takes the scratch buffer from its caller
(open_path's buffer is already large enough --
max_dirnamelen + max_capstrlen + namelen with namelen >= 1 covers the
max_dirnamelen + max_capstrlen + 1 print_search_path requires), so
LD_DEBUG=libs no longer pays for an extra allocation per open_path
invocation.
A new test elf/tst-dl-path-buf exercises the relevant paths -- dlopen
via DT_RPATH, open_path failure cleanup, dlopen with an over-long
name, dlopen from a PTHREAD_STACK_MIN thread.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
It allows it to return PTHREAD_STACK_MIN if defined.
Checked on x86_64-linux-gnu and with a build for i686-gnu.
Suggested-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Several loader code paths need a short-lived scratch buffer sized
by attacker-influenced inputs (RPATH entries, ld.so.cache strings,
etc.). The available primitives are all unsuitable:
- alloca is unbounded and can overflow PTHREAD_STACK_MIN stacks.
- <scratch_buffer.h> is unaware of __minimal_malloc: a malloc'd
spill freed during early loader startup silently leaks because
__minimal_free only releases the most-recent allocation.
- A few paths cannot route through the interposable malloc at
all -- ld.so.cache lookup in particular, because an interposed
user malloc may recursively call dlopen and __munmap the cache
mapping mid-copy (commit ccdb048d, "Fix recursive dlopen").
Add a loader-side analogue of <scratch_buffer.h>: a 256-byte inline
area for the common case, with spill to malloc by default or to
anonymous mmap when __minimal_malloc is active or the caller passes
DL_SCRATCH_NO_MALLOC. Mmap spills are tagged " glibc: loader
scratch" via __set_vma_name for /proc/self/maps visibility. On OOM
dl_scratch_buffer_allocate raises a loader error via _dl_signal_error
and does not return. The one-shot contract (no second allocate
without an intervening free) is enforced by an assertion in
_dl_scratch_buffer_allocate.
No functional change in this commit; consumers are added separately.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
A couple of small fixes for code readability, no functional change.
- Add missing comments for #endif statements.
- Move inclusion of string.h from malloc.c to calloc-clear-memory.h
where it is actually used.
- Re-order alias definitions for malloc functions.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
With the previous approach, the configure check fails for lld in version >=19.
While binutils and lld 18 is placing the R_390_IRELATIVE relocation in .rela.plt
and emits DT_JMPREL pointing to it, newer lld versions puts the R_390_IRELATIVE
relocation in .rela.dyn and therefore there is also no DT_JMPREL entry and the
configure check claims that lld does not support static-pie.
The R_390_IRELATIVE relocation is also processed fine in .rela.dyn, thus the
configure check is adjusted. Now the configure checks that it exists a
R_390_IRELATIVE relocation at all. If the R_390_IRELATIVE relocation lands in
.rela.plt, it ensures that there is DT_JMPREL pointing to it. Otherwise there
should be a .rela.dyn section.
Key optimizations:
- Use SVE predication for branch-free handling of short inputs and tails
- Use 4-way loop unrolling to maximize pipeline utilization
- Optimize mismatch detection with early exit logic
Benchmark (bench-memcmp, generic -> this patch):
- Small (0-128B): 15% - 50% speedup
- Medium (129-1024B): 21% - 50% speedup
- Large (2048-4096B): 28% - 50% speedup
Note: regressions may be observed in edge cases where offsets
are near 4K boundaries. These instances are rare and the overall
performance gain remains significantly positive.
Also add IFUNC support for memcmp and correct the first-line
comment in memcpy_kunpeng950.S.
tzdb 2026b no longer needs -Wno-discarded-qualifiers or
-Wno-unused-variable. From a suggestion by Joseph Myers in:
https://sourceware.org/pipermail/libc-alpha/2026-May/177312.html
* configure.ac (config-cflags-wno-discarded-qualifiers): Remove.
* timezone/Makefile (CFLAGS-zic.c): Remove -Wno-unused-variable,
$(config-cflags-wno-discarded-qualifiers).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Sync tzselect, zdump, zic to tzdb 2026b.
This fixes some buffer and integer overflows in zic,
adds new zic options -D, -m and -u inspired by FreeBSD,
and raises zic’s maximum number of abbreviation bytes
per timezone from 50 to 256.
This patch incorporates the following tzdb source code changes:
f9d30685 Output a minimal time zone designation table
37a4d178 Fix zic overflow bug with too-large offsets
4392f2dc zic now checks for signals more often
99a08a66 Fix zic buffer overflow when computing TZ
d63b9287 zic: keep needed last transition to new type
d005045d Pacify clang -Wunterminated-string-initialization
e67b08d3 Port to C23 strchr macro
3d4b4e46 Add zic.c overflow commentary
d9101b88 zic now a bit safer for overflows near 2**63
b23fa8e0 zic now allows more than 50 leap seconds
4ff518d2 Increase TZ_MAX_CHARS from 50 to 256
75d3b73b New -DTZ_RUNTIME_LEAPS=0 build-time option
87343c6e TZ_MAX_TIMES must be at least 310 now
fc8f1b68 Simplify int_fast32_t definition on C89 platforms
24581465 Remove TZDEFRULES ("posixrules") from localtime.c
fc708427 zic now warns about -p
b09a3f23 Port TWOS_COMPLEMENT to signed-magnitude hosts
56b7a24a Make sure 2**31 - 1 is signed
9068ab78 zic no longer generates utoff == -2**31
cb6f9b3b Omit unnecessary L suffixes
c37fbc32 Clarify when ‘__attribute__((pure))’ is a hack
859690a7 Fix some unsequenced/reproducible commentary
9c772ca7 Port to POSIX.1-2001 fflush
10f93018 Omit no-op transitions when Rule+Zone cancel
a0b09b52 Fix unlikely backslash bug in scripts
2cbd3a71 Allow builder to override GRANDPARENTED
c7257626 not used at → used outside
faed4bd3 Clarify <sys/auxv.h> vs getauxval
df08e6a1 Port mode_t (and gid_t, uid_t) to MS-Windows
6127d375 New zic option -u, inspired by FreeBSD
813c9ee0 New zic option -m, inspired by FreeBSD
987ea89c New zic option -D, inspired by FreeBSD
cc377b07 Simplify mkdir situation
cd994a90 Simplify !HAVE_POSIX_DECLS situation
052ddf76 Minor gettext macro improvements
d9018f1c Refactor duplicate duplicate-option code
8d65db97 Prefer fdopen to umask in zic
d7edca6e Omit “'”s from zic usage message
a09ba7a5 getopt returns -1 (not EOF) on failure
e22d410c zic now uses is_digit
f57cadda Always invoke umask at start
242a8338 Fix mode_t issues on MS-Windows
2fecd606 MKDIR_UMASK → MKDIR_PERMS refactoring
90ef088a Move static_assert to top level
41576478 Port better to platforms lacking mempcpy
90a08d3e * private.h: Include stddef.h early enough
aa8b35fe Simplify port to NetBSD struct __state
cd2fddf7 Port to -DHAVE_SYS_STAT_H=0 -DHAVE_POSIX_DECLS=0
8470e759 Pacify GCC 15 -Wunterminated-string-initialization
8817d42f Prefer mempcpy to doing it by hand
87abb113 Tighten security checks on TZ values
c87f0918 Use strnlen
07f7f31a Fix preprocessor indenting
3adf4123 Add offtime_r à la FreeBSD and NetBSD
b807a31e Don’t depend on ‘true’ for tzselect
ddffc800 * zic.c: Fix misspelled comment (thanks to Jonathan Wakely).
7063d08c Fix bug with -d RELATIVE -t ABSOLUTE
e8920e76 Rename emalloc to xmalloc.
e8e1a3d2 NetBSD defines STD_INSPIRED functions
3411494c Define _CRT_DECLARE_NONSTDC_NAMES for MS-Windows
7c909166 Define NOMINMAX for MS-Windows
24a4d97f 'zdump -' now reads from stdin
e6d6bc3e Pacify gcc -Wsuggest-attribute=format sans snprintf in zdump
99557862 TZNAME_MAXIMUM defaults to 254, not 255
fe5be99d Be more consistent about macro true/false vs 1/0
31f483a1 Remove dependency of asctime on strftime
7ef7ed06 Simplify timeoff redefinition
1bd67a4b Move MKTIME_MIGHT_OVERFLOW definition
67f7e8ab Pacify GCC 15ish -Wzero-as-null-pointer-constant
535a4e8b Pacify GCC 15ish -Wleading-whitespace=blanks
0706ef0b Move iinntt definition
ea814e99 strftime %s no longer is limited to time_t range
41e5344e Fix bug near the year 2**31 - 1 - 1900
4e1de249 Pacify gcc -Wsuggest-attribute=const
ebd2ed92 Don’t define _FILE_OFFSET_BITS if _TIME_BITS
26a649a1 Improve zdump overflow checking
9c8221d7 * private.h: Fix timeoff comment.
9db906a0 Switch from RFC 8536 to 9636 for documentation
af54a9e8 Port better to glibc when used internally there
Checked on x86_64-linux-gnu.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Benchmarks on Hygon processors show that the default non-temporal
threshold is higher than ideal for large copy workloads. As a result,
memcpy and memmove may continue to use the temporal copy path for
longer than is beneficial, increasing cache pollution and reducing
throughput for large copies.
Lower the copy non-temporal threshold to 3/8 of the shared cache size
per thread on Hygon. This allows the non-temporal copy path to be
selected earlier while leaving the memset non-temporal threshold
unchanged.
Signed-off-by: xiejiamei <xiejiamei@hygon.cn>
* libio/fmemopen.c: Reference pos the variable instead of c->pos.
On the edge case, one byte should be written at the end of buffer,
instead of returning error.
Signed-off-by: Rocket Ma <marocketbd@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
When a shared library is built with -z lazy and its IFUNC resolver calls
a PLT function, the dynamic linker can crash. The resolver runs while
the PLT stubs still hold their raw ELF virtual addresses — l_addr has
not yet been added — so the call branches to an unmapped address.
The old code deferred IRELATIVE entries only to the end of the relocation
range currently being processed (via the r2/end2 scan-ahead mechanism in
elf_dynamic_do_Rel). This was sufficient only when both IRELATIVE and the
JMP_SLOT entries for the PLT functions it needs are in the same section.
On x86-64, aarch64, arm, i386 and most other targets, a file-scope
initialiser of the form
int (*fptr)(void) = some_ifunc;
causes the linker to place R_*_IRELATIVE in .rela.dyn, while JMP_SLOT
entries for any PLT calls made by the resolver live in .rela.plt.
Processing .rela.dyn before .rela.plt means the resolver fires before the
PLT is usable, regardless of where within .rela.dyn IRELATIVE appears.
Fix this by splitting IRELATIVE processing into a separate, explicitly
deferred pass. In elf/do-rel.h:
- Remove the r2/end2 variables and the post-loop IRELATIVE re-scan from
elf_dynamic_do_Rel. IRELATIVE entries are now always skipped in the
non-bootstrap path.
- Add a new elf_dynamic_do_Rel_irelative function that scans a
relocation range and calls elf_machine_rel/elf_machine_lazy_rel for
IRELATIVE and ifunc relocations.
In elf/dynamic-link.h, update _ELF_DYNAMIC_DO_RELOC to use a two-phase
approach for non-bootstrap builds unconditionally (regardless of whether
ranges[1].size is zero):
Phase 1+2: elf_dynamic_do_Rel over .rela.dyn then .rela.plt — processes
everything except IRELATIVE/STT_GNU_IFUNC.
Phase 3+4: elf_dynamic_do_Rel_irelative over .rela.dyn then .rela.plt —
processes only IRELATIVE, by which point all PLT stubs are
valid.
This guarantees that IRELATIVE resolvers can call PLT stubs safely
regardless of which section the linker placed R_*_IRELATIVE in.
Add ELF_MACHINE_IRELATIVE to the architectures that were missing it so
the new skip logic in elf_dynamic_do_Rel is compiled for all targets.
This patch addresses the binutils BZ 13302 [1] from the glibc side, and
also fixes the mold-reported issue [2], which shows that IFUNC relocation
placement and processing can work differently across ABIs.
I checked on all ABIs that support IFUNC (x86_64, i686, aarch64, arm,
loongarch, powerpc, riscv, s390, and sparc), some via qemu-system.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=13302
[2] https://github.com/rui314/mold/issues/1550
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
v2: Update documentation
Whenever a large mmap is released the mmap and trim thresholds are updated.
As a result these thresholds grow ever larger which means huge allocations
are always served by arenas rather than mmap. The thresholds can end up as
large as an arena, which completely stops all trimming of the top block.
Remove the code completely - the default thresholds seem way too low for
modern 64-bit targets, but they can be increased seperately.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
When _nl_explode_name() returns -1 (out of memory) and the locale was
resolved through an alias, _nl_find_domain() returns immediately
without freeing the locale copy allocated earlier. Similarly,
when _nl_make_l10nflist() returns NULL, the 'goto out' skips the
alias_value free.
Fix by nesting the _nl_make_l10nflist() call and its result handling
inside 'if (mask != -1)' instead of returning early. Move the
normalized_codeset free inside the same block. Both failure paths
now fall through to the unconditional alias_value free at the end.
Imported from GNU gettext commit 10eafd9e5.
Original author: Bruno Haible <bruno@clisp.org>
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
glibc requires C11 since 2022, making pre-C99 compatibility
paths in plural-exp.c dead code:
- init_germanic_plural(): With C99+, GERMANIC_PLURAL is
initialized at compile time and this function is never called.
Remove the function and the INIT_GERMANIC_PLURAL macro.
- HAVE_STRTOUL guard: Protected strtoul() usage with a manual
digit-parsing fallback. strtoul is in C89 <stdlib.h> and glibc
provides it. Remove the guard and the fallback loop.
Imported from GNU gettext commits ab5990532 and c1d84d656.
Original author: Bruno Haible <bruno@clisp.org>
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
PRI_MACROS_BROKEN was a workaround for AIX 4, where inttypes.h
did not properly define the PRI* format macros (PRId8, PRIu32, etc.).
glibc has never supported AIX, the macro was always hardcoded to 0
under _LIBC, making it a dead code.
GNU gettext removed this in commit 267f61670 ("Drop portability to
AIX 4"), since no supported system has broken PRI macros post-C99.
Based on GNU gettext commit 267f61670.
Original author: Bruno Haible <bruno@clisp.org>
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Remove all IN_LIBGLOCALE conditional blocks from intl/. libglocale
was a proposed API from 2005 that was never completed or shipped.
The macro is never defined in glibc or in current GNU gettext, making
every #ifdef IN_LIBGLOCALE block dead code.
GNU gettext removed these in commits starting from 2023. Removing
them from glibc reduces noise and eases future syncs with gettext.
Imported from GNU gettext commit d6a6801c1.
Original author: Bruno Haible <bruno@clisp.org>
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The failure tail of __libc_arm_za_disable only leads to
__libc_fatal, so it does not need to preserve call frame state.
Remove the PAC prologue, frame setup, saved cntd value, stack
stores, and associated CFI directives from the fatal path, leaving
only the required SME state shutdown and fatal call.
Add tst-sme-za-disable-fail to exercise the abort path by providing
a TPIDR2 block with non-zero reserved bytes and checking that the
process terminates with SIGABRT and the expected fatal message.
clang does not recognize the 'm' scanf specifier and incorrectly warns
that the buf argument may overflow. Suppress the warning with the
clang-specific DIAG_* macros.
The fix for BZ 26577 ("Fix stack overflow in _dl_map_object_from_fd
with large e_phnum") removed the alloca for the program-header table
and introduced a streaming iterator (dl_pt_load_iterator) so segments
could be walked without staging the entire table on the stack.
That patch batched reads correctly in _dl_map_object_scan_phdrs (the
first walk, which collects PT_DYNAMIC/PT_TLS/PT_GNU_* metadata), but
overlooked the second walk in _dl_map_segments:
_dl_pt_load_iterator_next issued one pread64 per program header to
find the next PT_LOAD entry. For an object with N program headers
this added N redundant per-phdr syscalls on every dlopen / loader
startup -- regardless of whether the table had already been read by
open_verify into struct filebuf.
Unify both walks behind a single batched helper,
_dl_pt_load_iterator_phdr_at:
- When the program header table fits in the bytes already read by
open_verify into fbp->buf (the common case for nearly all shared
objects), all phdr accesses are served from that buffer with no
syscall at all.
- Otherwise, up to FILEBUF_SIZE / sizeof(ElfW(Phdr)) program headers
are read into fbp->buf with a single pread64; subsequent indices
in the same window hit the buffer.
Both _dl_map_object_scan_phdrs and _dl_pt_load_iterator_next now go
through this helper, eliminating the separate batching logic in
_dl_map_object_scan_phdrs. struct filebuf moves from dl-load.c to
dl-load.h so the inline iterator in dl-map-segments.h can reach
fbp->buf.
The filebuf size is also bumped to ensure the cached fast path
triggers for all observed binaries. A survey of an Ubuntu 24.04
installation (scanning /usr) shows:
Candidate files : 465834
ELF files inspected : 11624
glibc-linked binaries : 10164
Minimum e_phnum : 5
Maximum e_phnum : 14
Average e_phnum : 11.37
Median e_phnum : 11.0
shows e_phnum capped at 14 (for instance gcc's cc1, lto1, perl,
and gdb). The previous FILEBUF_SIZE of 832 on 64-bit fit only 13
program headers after the ELF header (64 + 13*56 = 792), so 64-bit
binaries with 14 phdrs missed the cached path. FILEBUF_SIZE is
bumped from 512/832 to 640/1024 (32-bit / 64-bit) -- enough for at
least 16 program headers on either ABI, leaving headroom over the
observed maximum.
For a typical shared library where open_verify's initial read covers
the program header table, this reduces _dl_map_segments from N
preads to 0. For a worst-case e_phnum that does not fit in fbp->buf,
reads drop from N to ceil(N / phdrs_per_buf) -- the same cost
_dl_map_object_scan_phdrs already pays.
No functional change. Tested on x86_64-linux-gnu, aaarch64-linux-gnu,
and i686-linux-gnu.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
_IO_new_file_init_internal linked the new stream into _IO_list_all
before setting fp->_fileno to -1. A concurrent thread that walks
_IO_list_all (for example via fflush (NULL)) could observe the stream
with an uninitialized _fileno before initialization completed.
Set _fileno = -1 before _IO_link_in so the stream is fully
initialized when it becomes visible in the global list.
This is the residual concurrency defect noted at the end of commit
b657f72fa3 ("libio: Fix deadlock between freopen, fflush (NULL) and
fclose (bug 24963)").
Add libio/tst-file-init-race exercising concurrent fopen/fclose and
fflush (NULL) to detect regressions.
Signed-off-by: Shamil Abdulaev <ashamil435@gmail.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Add a new internal test, `tst-wcsmbs-clone-overflow`, to verify correct
gconv module reference counting. The Makefile is updated to include this
test in the `tests-internal` list and ensure it runs with generated locales.
This test specifically checks that the `__counter` for `gconv_fcts->towc`
does not leak references when `swscanf` is used with a stack-allocated
wide character stream. It ensures that `_IO_wstrfile_fclose_stack`
properly decrements the module reference counter, preventing a module
from staying loaded indefinitely due to unreleased references.
Assisted-by: LLM
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The swscanf family of functions creates a wide-oriented FILE stream
on the stack. Initialization of this stream invokes `_IO_fwide`, which
clones the global locale's gconv transformation steps via
`__wcsmbs_clone_conv`. This increments the reference counter (`__counter`)
of the gconv module.
Because the FILE stream is stack-allocated, `fclose` cannot be called,
and so `__gconv_release_step` is never invoked. The counter leaks,
eventually hitting the 32-bit integer overflow limit and aborting the
process.
To resolve this, we introduce `_IO_wstrfile_fclose_stack`, a dedicated
cleanup function for stack-allocated FILE streams. This function invokes
`_IO_FINISH` and correctly releases the gconv steps via
`__gconv_release_step` without attempting to `free` the FILE pointer.
This cleanup function is then hooked into all variants of swscanf right
before they return.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The ELF loader allocates the program-header table on the stack with
alloca(e_phnum * sizeof(ElfW(Phdr))) in two places: once in
open_verify to call elf_machine_reject_phdr_p, and again in
_dl_map_object_from_fd to scan segment types. Both fall back to
alloca only when the table does not fit in the initial fbp->buf read;
for a crafted ELF with e_phnum == 0x7FFF this means up to ~1.8 MB
(32767 × 56 bytes on a 64-bit host) on the stack in each call, with
no guard against the combination exhausting the available stack space.
A latent variant of this problem exists even for ordinary shared
libraries when dlopen is called from a thread running with
PTHREAD_STACK_MIN stack (16 KB on Linux). The nptl/tst-minstack-exit
test demonstrates that glibc code paths must operate correctly under
minimum-stack conditions; loading a shared library with even a modest
number of program headers can overflow the remaining stack through the
alloca-based phdr table.
This patch eliminates both allocas by replacing them with a single
_dl_map_object_scan_phdrs function that reads program headers in
fixed-size chunks into the existing fbp->buf scratch buffer (512 B on
32-bit, 832 B on 64-bit) using pread. When all headers fit within
the bytes already captured by open_verify's initial read() call (the
common case), no extra syscall is needed. This should be the case for
most of the ELF objects and should not required additional syscalls.
The slow path issues as many pread calls as necessary without any stack
growth proportional to e_phnum. The elf_machine_reject_phdr_p interface
is redesigned around a new struct dl_machine_phdr_info and on MIPS this
captures the PT_MIPS_ABIFLAGS entry in-flight, so the compatibility check
in elf_machine_reject_phdr_p no longer needs to re-scan the program-header
table.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
NB: this patch depends on https://sourceware.org/pipermail/libc-alpha/2026-May/177239.html
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The _dl_map_object_from_fd uses a VLA (loadcmds[l->l_phnum]) whose size
is proportional to e_phnum. A crafted ELF with e_phnum == 0x7FFF
allocates ~1.5 MB (32767 × 48 bytes on 64-bit machine) on the stack,
which adds to the previous ~1.75 MB alloca for the phdr table that
precedes it.
This patch follow Florian's suggestion [1] to use a two-pass approach
(collect-then-map) with a single-pass struct dl_pt_load_iterator that
precomputes the metadata needed by _dl_map_segments (p_align_max,
has_holes, first/last segment bounds, nloadcmds) and then yields one
struct loadcmd at a time through _dl_pt_load_iterator_next, holding at
most one loadcmd on the stack at a time. The same iterator is
threaded through _dl_map_segments in dl-map-segments.h.
The main complex part is the test, which adds python-generated crafted
ET_DYN that has e_phnum == 0x7FFF: one PT_LOAD covering the ELF header
so the loader exercises the full iterator path, and the remaining
headers PT_NULL. The test runs two subtests under a reduced stack limit
(phdr alloca + 1 MB headroom ≈ 2.75 MB, well below the 3.25 MB the
unfixed VLA code requires).
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
[1] https://sourceware.org/pipermail/libc-alpha/2026-February/175136.html
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The first test checks for stack overflow. It uses a plural expression
nested 5000 levels deep using the !(1-(...)) pattern. The parser
accepts it (below YYMAXDEPTH=10000), but evaluation exeeds
EVAL_MAXDEPTH=100 and falls back to index 0 instead of crashing with
SIGSEGV.
The second test checks for division by zero in plural expression. The
expression (n!=1)+1/(n!=1729) triggers 1/0 for n=1729. msgfmt only
validates 0<= n <= 1000, so the .mo file is accepted. Evaluation
returns PE_INTDIV and falls back instead of raising SIGFPE.
Adaptations from gettext to glibc:
- gettext's plural-3 embeds the nested expresion as a literal string.
This test uses an AWK script (plural-depth.awk) to generate the same
expression.
- gettext uses LANGUAGE= (empty) with LC_ALL=ll and its own locale
setup. glibc requires a real locale for setlocale() or else the "C"
locale override in dcigettext.c ignores LANGUAGE entirely.
The tests are derived from GNU gettext's plural-3 (commit 021348871a22)
and plural-4 (commit 429ba6c6b835), adapted to glibc's test framework.
Original author: Bruno Haible <bruno@clisp.org>
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The plural expression evaluator plural_eval() in eval-plural.h uses
unbounded recursion, which can cause a stack overflow crash with
deeply nested expressions in malicious .mo files. This is
particularly dangerous on threads with small stacks (musl libc
default: 128 KB, AIX 7 default: 96 KB, glibc after ulimit -s 260:
~3919 recursions max).
Additionally, division by zero in plural expressions triggers
raise(SIGFPE), which is not multithread-safe, catching SIGFPE
requires per-process signal handlers that race with other threads.
Fix both by importing the hardening from GNU gettext:
- Replace unbounded plural_eval() with depth-limited
plural_eval_recurse() (EVAL_MAXDEPTH=100), returning a
struct eval_result with status instead of a bare unsigned long.
- Return PE_INTDIV status on division by zero instead of raising
SIGFPE. Remove the architecture-specific INTDIV0_RAISES_SIGFPE
macro and the conditional #include <signal.h>.
- Update plural_lookup() in dcigettext.c to handle the new return
type, falling back to index 0 on any evaluation failure.
Based on GNU gettext commits ef37a1540 and 726bfb1d1.
Discussed on: https://sourceware.org/pipermail/libc-alpha/2023-October/152010.html
Original author: Bruno Haible <bruno@clisp.org>
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It requires proper gcc support [1], and without proper compiler support
the arm configure disable static-pie support.
The start.S requires some adjustment to avoid loading main from
the GOT.
Checked on arm-linux-gnueabihf with and without the gcc patch applied.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598610.html
Reviewed-by: Yury Khrustalev <yury.khrustalev@arm.com>
Reviewed-by: Sam James <sam@gentoo.org>
The following functions:
__aio_create_helper_thread
__aio_start_notify_thread
__gai_create_helper_thread
__gai_start_notify_thread
are declared as extern inline, but no translation unit provides their
real definitions. This can lead to a link failure if the functions are
not inlined. Fix it by declaring them as static inline instead.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
This patch adds an RVV-optimized implementation of strncmp for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__strncmp_vector) is added
alongside the generic fallback (__strncmp_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling strncmp().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
This patch adds an RVV-optimized implementation of strcmp for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__strcmp_vector) is added
alongside the generic fallback (__strcmp_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling strcmp().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
Some tests use pointers after the associated memory has been freed.
On targets that support memory tagging, using such pointers even
for test purposes might be impossible. To work around this, we add
new function that would allow to clear a pointer in a target-specific
way.
We modify 3 relevant malloc tests: tst-malloc-backtrace, tst-tcfree3,
and tst-safe-linking.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* stdio-common/vfscanf-internal.c: When enlarging allocated buffer with
format %mc or %mC, glibc allocates one byte less, leading to
user-controlled one byte overflow. This commit fixes BZ #34008, or
CVE-2026-5450.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Rocket Ma <marocketbd@gmail.com>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Use the C23 <stdbit.h> rotation helpers instead of inline assembly
for pointer mangling and demangling on i386.
The PTR_MANGLE and PTR_DEMANGLE macros previously used rol/ror
inline asm with a constant rotation of 9. Replace these with
stdc_rotate_left and stdc_rotate_right operating on uintptr_t,
preserving the exact rotation count via 2 * sizeof (uintptr_t) + 1.
This change removes inline assembly, improves portability and
readability and lets the compiler select optimal code generation.
No functional change intended.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Use the C23 <stdbit.h> rotation helpers instead of inline assembly
for pointer mangling and demangling on x86_64.
The PTR_MANGLE and PTR_DEMANGLE macros previously used rol/ror
inline asm with a constant rotation of 2 * LP_SIZE + 1. Replace
these with stdc_rotate_left and stdc_rotate_right operating on
uintptr_t, preserving the exact rotation count via
2 * sizeof (uintptr_t) + 1.
This change removes inline assembly, improves portability and
readability and lets the compiler select optimal code generation.
No functional change intended.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It follows the C2y N3367 proposed interface, along with some tests
imported from gnulib (and adapted to glibc libsupport).
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Contributions made under DCO use a generic statement to indicate that
the file has copyright, but that statement does not need to include a
year. Remove the year to avoid the work required to update that
statement to include future years as such updates are not required.
* libio/wgenops.c: When _IO_wdefault_pbackfail attempts to push back one
character, it accidently compare the wchar to push back with the last
char from byte stream, instead of wide stream. Under specific coding,
attacker may exploit this to leak information. This commit fix bug
33998, or CVE-2026-5928.
Signed-off-by: Rocket Ma <marocketbd@gmail.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
When __builtin_stdc_rotate_right is supported, glibc defines type-specific
aliases for several unsigned integer types (uc, us, ui, ul), but omits the
unsigned long long variant. This leads to an inconsistency between the
builtin-backed path and the generic fallback, where unsigned long long
is handled.
Add the missing stdc_rotate_right_ull macro mapping to
stdc_rotate_right(__x, __n) to complete the set of type-specific helpers
and ensure consistent API coverage across all supported unsigned integer
types.
No functional change for existing users; this only exposes the expected
alias for unsigned long long.
Fixes: 331c7a4cd0 ("stdbit: Fix builtin name used in __glibc_has_builtin check for rotate_right")
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
The __glibc_has_builtin check in include/stdbit.h incorrectly refers to
___builtin_stdc_rotate_right (with three leading underscores) instead of the
correct __builtin_stdc_rotate_right (two leading underscores). As a result,
the builtin is not detected even when supported by the compiler.
Fix the spelling to use __builtin_stdc_rotate_right consistently in both the
feature test and the corresponding comment.
Fixes: 4adae8550a ("stdlib: Add internal stdc_rotate_right implementation")
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch adds an RVV-optimized implementation of strlen for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__strlen_vector) is added
alongside the generic fallback (__strlen_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling strlen().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
If /dev/null is bind-mounted, /dev and /dev/null are on different
devices, so the expected failure has an additional line describe
the device change.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Update the South Korean (ko_KR) locale to reflect official standards:
- LC_ADDRESS: Follow the Large-to-Small hierarchy (Country, Postcode,
City, Road, Recipient) as per Korea Post guidelines.
(https://www.koreapost.go.kr/kpost/subIndex/135.do?pSiteIdx=125)
- LC_NAME: Follow the standard Korean order (Surname + Given Name)
without Western-style salutations or tabs.
* localedata/locales/ko_KR (LC_ADDRESS): Update postal_fmt.
* localedata/locales/ko_KR (LC_NAME): Update name_fmt to "%f%g".
Signed-off-by: Jiho Lee <elmitash@gmail.com>
Reviewed-by: Arjun Shankar <arjun@redhat.com>
Extend the Prefer_No_AVX512 tuning to cover Hygon model 0x8.
Benchmarks on Hygon platforms show that EVEX implementations
are often more profitable than AVX512 paths. The existing logic
already enables Prefer_No_AVX512 for model 0x7. Apply the same
preference to model 0x8 to ensure consistent IFUNC selection
behavior across newer Hygon processors.
Signed-off-by: xiejiamei <xiejiamei@hygon.cn>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* stdio-common/reg-modifier.c: The wchar in str can be greater or equal
than 0, and less or equal than UCHAR_MAX, that means, we need a buffer
with UCHAR_MAX + 1 elements, so that user input will not overflow
__printf_modifier_table.
Signed-off-by: Rocket Ma <marocketbd@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Make the result checkable from the command line even without verbose
mode. Keep original exit status 2 for name not found error. But report
other errors by exit status greater than 10.
For too high values make it return 2 as before.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Unlike older hosts database served by gethostbyname, getaddrinfo call
can return varying return codes. Those codes can be vital for providing
reason why name resolution on the system did not return address. Even
when getent tool is usually present on every small container image,
there is often no helpful tool to show getaddrinfo errors.
This simple change adds verbosity flag to getent. With that it can
provide more details about the reason of the failure. It can help to
obtain information whether the name queried exists or does not have
address of requested types only.
The only database where this will help is ahosts* variants. I have not
found any kind of test to expand with new verbose flag. But I think this
would be very useful on various limited system, where bind-utils is not
installed by default. Besides, sometimes getaddrinfo call can return
different information than DNS protocol itself.
Example of usage:
nss/getent -v ahosts com.
This will tell you the name exists, but has no address.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
If __read_nocancel fails or overflows the buffer, the function returned
without closing the /sys/kernel/mm/transparent_hugepage/enabled fd.
Found while investigating BZ #34083.
Signed-off-by: Shamil Abdulaev <ashamil435@gmail.com>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The cve.mitre.org site is an archive that redirects users to cve.org.
The linked about page has also been removed, so this patch changes it to
reference the current equivalent on cve.org.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
It is a fix for memory leak in the function 'newlocale' (the real name is __newlocale).
There is not released a memory for the local buffer 'locale_path'.
https://sourceware.org/bugzilla/show_bug.cgi?id=25770
---
Patch was tested on Ubuntu 24.04.
My 'LOCPATH' environment variable is "/snap/code/193/usr/lib/locale".
With an original (system) libc I have the following problem:
#0 0x7d5c3aafc778 in realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:85
#1 0x7d5c394b05f2 in __argz_add_sep string/argz-addsep.c:34
#2 0x7d5c39439bdb in __newlocale locale/newlocale.c:111
#3 0x7d5c370e58fc (/lib/x86_64-linux-gnu/libp11-kit.so.0+0x1098fc) (BuildId: 1cbcd6ac7e0ff0259eb3acc14d556d2c1ec00cdc)
#4 0x7d5c3b14571e in call_init elf/dl-init.c:74
#5 0x7d5c3b145823 in call_init elf/dl-init.c:120
#6 0x7d5c3b145823 in _dl_init elf/dl-init.c:121
#7 0x7d5c3b15f59f (/lib64/ld-linux-x86-64.so.2+0x1f59f) (BuildId: 1c8db5f83bba514f8fd5f1fb6d7be975be1bb855)
SUMMARY: AddressSanitizer: 46 byte(s) leaked in 1 allocation(s).
When I run with my corrected libc, through runtest.sh <my-application>, all is OK.
Signed-off-by: Dmitry Kovalenko <d.kovalenko@postgrespro.ru>
Co-authored-by: Florian Weimer <fweimer@redhat.com>
The existing paragraph warning about _FILE_OFFSET_BITS default changes
due to Y2038 is correct but confusing, as it does not explicitly state
why time_t concerns affect _FILE_OFFSET_BITS.
Clarify that _TIME_BITS=64 (needed for Y2038 safety) requires
_FILE_OFFSET_BITS=64, so when systems migrate to 64-bit time_t by
default, _FILE_OFFSET_BITS will also need to default to 64, even for
applications that do not handle large files.
This addresses the confusion noted in the bug report while keeping the
warning in place, as the transitive dependency makes it relevant to
the _FILE_OFFSET_BITS documentation.
Signed-off-by: Shamil Abdulaev <ashamil435@gmail.com>
* misc/getusershell.c: Completely rewrite the unit. Only allocate one
big buffer to store shell names. Add a missing unit test.
The new implementation read the whole file into one buffer, and wipe out
every byte but shell names. Later when addressing shell names from first
shell, jump to next '\0' and then jump to next '/'. This could reduce
memory footprint and shall improve some performance.
Signed-off-by: Rocket Ma <marocketbd@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
With commit 6c3a8a9d86 (2018-08-25), the test
used xmalloc instead of malloc and therefore removed the path == NULL check
as xmalloc is printing an error message and exit with a fail in this case.
On s390-32 this was always a FAIL instead of UNSUPPORTED, thus the previous
behaviour was re-enabled with commit 3bad2358d6
five days later on 2018-08-30. Therefore, we don't know if this also happens
on other systems.
While removing s390-32 with commit b01debcd8f
I've adjusted the comment and Adhemerval asked whether this can also happen
on other systems with little physical memory. We've decided to remove the
EXIT_UNSUPPORTED in this extra commit instead of the large s390-32 removal one.
See libc-alpha:
https://inbox.sourceware.org/libc-alpha/20260409085102.3475867-1-stli@linux.ibm.com/T/#m28b5375bef4cfb10729b93c7e658b91a14b07b85
If this change leads to test fails somewhere, please add a comment about your
used system and revert this commit.
Nowadays path is allocated with support_blob_repeat_allocate which returns
an empty struct in case of malloc/mmap is not able to allocate enough memory.
All other tests using support_blob_repeat_allocate
(stdlib/tst-strtod-overflow.c, support/tst-support_blob_repeat.c and
string/tst-memmove-overflow.c) are properly checking the start or size field
directly or indirectly via TEST_COMPARE_BLOB.
While the test support/tst-support_blob_repeat.c just prints a warning if
allocating the large mappings is not possible, the other tests exit with
UNSUPPORTED.
At least for the realpath-part, the commit
855a67c3cc introduced support_accept_oom handling.
According to the discussion:
https://inbox.sourceware.org/libc-alpha/8a1fd5b2-5118-498e-babf-e46c0e6d1cdf@redhat.com/
Agreed, test-bz22786 can use a lot of memory.
OK. These convert OOM to UNSUPPORTED for the test if there isn't enough memory.
In case of not enough memory while allocating path, this change would lead to a
segmentation fault instead of UNSUPPORTED. As this is inconsistent compared to
the second realpath-part and also to the other tests using
support_blob_repeat_allocate, I would prefer keeping UNSUPPORTED if path is NULL.
Nevertheless, I've posted this patch for discussion as promised while reviewing
the s390-32 removal patch.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Use new way of handling test tunables for BTI and GCS tests.
Fix tests that would fail when ambient GLIBC_TUNABLES variable
is used with the aarch64_gcs tunable.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Many tests use Glibc tunables, and the values of the tunables are
provided via the GLIBC_TUNABLES env variable. Tests set it in
makefiles using
tst-foo-ENV = GLIBC_TUNABLES=tunable=value
This overwrites environment for this test, so if another env var is
set elsewhere, one of these changes would be lost. The correct way
should be to append to test's environment:
tst-foo-ENV += GLIBC_TUNABLES=tunable=value
However, if two or more tunables need to be set for the same test,
the 'tunable=value' part should be appended to previously defined
GLIBC_TUNABLES env variable, and it's not easy to achieve this via
existing tools available for tests.
Additionally, there are cases when it is useful to set ambient env
var GLIBC_TUNABLES in order to apply it to most of the tests except
those that require specific tunables. The existing mechanism that
relies on tst-foo-ENV would always override the ambient env var
even when it is not desirable.
To address all of this, in this commit we add support for using
constructs like
tst-foo-TUNABLES += tunable=value
Using this, the test will receive appropriate GLIBC_TUNABLES contents,
and if there is an ambient env var GLIBC_TUNABLES, its value will be
prepended to the env var used by the test. Even if the ambient env var
contains the same tunable that is used by a test, the test's value will
override the ambient value, and the test will be executed correctly.
Additionally, we support cases when tests must have specific value
of the GLIBC_TUNABLES env var (ignoring any ambient value):
tst-foo-TUNABLES-only += tunable=value
The existing mechanism that uses tst-foo-ENV will continue to work,
however if the same test uses both, the new mechanism will override
the old one.
Additional benefit is that the code in makefiles becomes shorter.
We also change tunable handling for malloc tests in this commit.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch adds an RVV-optimized implementation of memcpy for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__memcpy_vector) is added
alongside the generic fallback (__memcpy_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling memcpy().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
Some malloc tests compare pointers meaning to compare addresses.
On AArch64, the 64-bit value of the pointer may contain metadata
along with the values of the address.
In order to correctly compare addresses, we add new function for
AArch64 target that will use the AArch64 64 SUBP (subtract pointer)
instruction when it is available. This instruction uses the 56-bit
addresses ignoring top-byte metadata.
Best implementation is selected using ifunc resolver.
On other targets and also on AArch64 when MTE is not available this
function defaults to PTR_DIFF defined in libc-pointer-arith.h.
Three malloc tests are modified accordingly:
- tst-memalign-2.c
- tst-memalign-3.c
- tst-realloc.c
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
This patch adds an RVV-optimized implementation of strcpy for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__strcpy_vector) is added
alongside the generic fallback (__strcpy_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling strcpy().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
While review of s390-32 removal, Adhemerval asked if those CFLAGS are still
necessary:
https://inbox.sourceware.org/libc-alpha/20260409085102.3475867-1-stli@linux.ibm.com/T/#me5120906445f3941031e29c3a093f1699eae77b4
According to the git-history, the first s390-Makefile was introduced back in
2000-08-02 with those CFLAGS. The same are also included now and past in
i386-Makefile. But I haven't found a reason why those were added in the past
and if it was really necessary on s390. I assume it was with old GCCs most
likely due to inclusion of dl-machine.h.
This patch removes those CFLAGS. If needed, we have to circumvent the issues
again. At least I've used current GCCs 12.5, 13.4, 14.3, 15.2 and gcc-head
to successfully build current glibc on s390-64 with -O2, -O3 and -Os without
such warnings.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Vector variants of the new C23 powr routines.
These provide same maximum error error as pow by virtue of
relying on shared approximation techniques and sources.
Note: Benchmark inputs for powr(f) are identical to pow(f).
Performance gain over pow on V1 with GCC@15:
- SVE powr: 10-12% on subnormal x, 12-13% on x < 0.
- SVE powrf: 15% on all x < 0.
- AdvSIMD powr: for x < 0, 40% if x subnormal, 60% otherwise.
- AdvSIMD powrf: 4% on x subnormals or x < 0.
Optimize handling of subnormal x and/or negative x.
Some cleanup in attributes, macros and improving overall consistency.
Move core computation to header
Introduce config parameter to turn sign_bias on/off.
Performance improvement on V1 with GCC@15:
- AdvSIMD pow: 10-15% on subnormals.
- AdvSIMD powf: 30 to 70% on subnormals or x < 0, <=3% on x > 0.
- SVE pow: 10-15% on subnormals, <=3% otherwise.
- SVE powf: no significant variations in codegen/perf.
Remove wordsize-64 and arch-specific implementations, for ABIs when
off_t is the same as off64_t (__OFF_T_MATCHES_OFF64_T) the ftw64.c
will create the requires aliases.
The ftw.c implementation is moved to ftw-common.c to simplify
the __OFF_T_MATCHES_OFF64_T usage.
Remove wordsize-64 and arch-specific implementations, for ABIs when
off_t is the same as off64_t (__OFF_T_MATCHES_OFF64_T) the fts64.c
will create the requires aliases.
The fts.c implementation is moved to fts-common.c to simplify
the __OFF_T_MATCHES_OFF64_T usage.
This patch adds an RVV-optimized implementation of strcat for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__strcat_vector) is added
alongside the generic fallback (__strcat_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling strcat().
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
After removing the files in s390-32 subfolder, we can also remove the
entries in CONTRIBUTED-BY file.
The entries for s390-64 files were adjusted to fit to the new paths.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
All the files in subfolders s390/s390-64 in sysdeps directory are moved
up to the s390/ ones. If necessary the files were merged with the existing
ones.
sysdeps/s390/preconfigure.ac was updated to reflect the removal of s390-64
subdirectory.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The removal of s390-32 allows us to switch to common-code headers
instead of providing s390-64 specific headers:
from sysdeps/unix/sysv/linux/s390/bits/environments.h
to bits/environments.h
-> We now only have a 64bit environment.
from sysdeps/s390/s390-64/bits/wordsize.h
to sysdeps/wordsize-64/bits/wordsize.h
-> All macros are defined equal
from sysdeps/unix/sysv/linux/s390/bits/utmp.h
to bits/utmp.h
-> On s390-64, __WORDSIZE_TIME64_COMPAT32 is defined to 0, then the
64bit part of both headers is identical
from sysdeps/unix/sysv/linux/s390/bits/utmpx.h
to sysdeps/gnu/bits/utmpx.h
-> On s390-64, __WORDSIZE_TIME64_COMPAT32 is defined to 0, then the
64bit part of both headers is identical
from sysdeps/unix/sysv/linux/s390/bits/timesize.h
to bits/timesize.h
-> __TIMESIZE is defined to 64 in both cases
from sysdeps/unix/sysv/linux/s390/bits/procfs-id.h
to sysdeps/unix/sysv/linux/bits/procfs-id.h
-> The typedefs for __pr_uid_t and __pr_gid_t on s390-64 are equal
in both files. No need for an extra s390-specific header file anymore.
from sysdeps/unix/sysv/linux/s390/bits/procfs-extra.h
to sysdeps/unix/sysv/linux/bits/procfs-extra.h
-> Get rid of the "32-bit variants so that BFD can read 32-bit core files."
Furthermore it turned out that there is a hardcoded implementation
independent of procfs-extra.h in <binutils>/bfd/elf32-s390.c:
elf_s390_grok_prstatus(), elf_s390_grok_psinfo().
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch removes s390-32 specific code in either common-code files
or shared files between s390-64 and s390-32.
Such code was guarded with preprocessor guards which check the size
of __WORDSIZE or __ELF_NATIVE_CLASS and of course the existance of
__s390x__ and __s390__ macros.
Note, that if __s390x__ is defined then __s390__ is also defined.
This patch also adjust guards for __s390__ only to __s390x__ to
make clear that those are still needed.
Futhermore the macro names for ifunc variants were adjusted from
XYZ_Z900_G5 to XYZ_Z900 as G5 is a pre 64bit machine.
On s390-32 we've used the special assembler directive to enable
zarch instructions:
.machinemode "zarch_nohighgprs"
As this is not needed on s390-64 anymore as zarch is enabled by default,
just drop those lines.
Furthermore we do not check for HWCAP_S390_ZARCH and HWCAP_S390_HIGH_GPRS
anymore. Just simplify those checks for e.g. stfle- or cuXY-instructions.
The 32/64 abi-variants and the corresponding abi-conditions are now also
removed from the s390 Makefiles and thus we now only generate a single
gnu/stubs.h and gnu/lib-names.h file instead of also having the different
ones for both abi-variants.
After removing process_elf32_file in s390 readelflib.c, ldconfig is only
recognizing 64bit ELF files for ld.so.cache.
Various comments mentioning s390 (with meaning s390-32) were removed/adjusted.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The linux 6.19 release has removed support for compat syscalls on s390x.
Therefore s390-linux-gnu (31bit) configuration was deprecated with glibc 2.43:
commit 638d437dbf
"Deprecate s390-linux-gnu (31bit)"
While deprecation, the build-many-glibcs.py script has already removed s390 (31bit).
Now explicitely exit with an error in sysdeps/s390/preconfigure
if somebody tries to build glibc for s390 (31bit).
Furthermore all s390-32 specific files are removed.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Add a new test to verify that large executable PT_LOAD segments are
mapped at addresses aligned to the THP size when the glibc tunable
glibc.elf.thp=1 is enabled and the system is configured to use THP
in "always" mode.
The test loads a shared object with a sufficiently large executable
segment via dlopen and inspects /proc/self/maps to check that the
mapping address is aligned to the THP page size reported by the kernel.
The test is skipped if the THP size cannot be determined or if THP is
not enabled in "always" mode.
Signed-off-by: WANG Rui <wangrui@loongson.cn>
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
cbaud_to_speed defined without condition, but used
if TEST_COMPAT (libc, GLIBC_2_0, GLIBC_2_42)
If the condition is not met, a defined but not used
warning will be issued.
Define cbaud_to_speed if TEST_COMPAT (libc, GLIBC_2_0, GLIBC_2_42)
is true.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Follow the example in iso-2022-jp-3.c and use the __count state
variable to store the pending character. This avoids restarting
the conversion if the output buffer ends between two 4-byte UCS-4
code points, so that the assert reported in the bug can no longer
happen.
Even though the fix is applied to ibm1364.c, the change is only
effective for the two HAS_COMBINED codecs for IBM1390, IBM1399.
The test case was mostly auto-generated using
claude-4.6-opus-high-thinking, and composer-2-fast shows up in the
log as well. During review, gpt-5.4-xhigh flagged that the original
version of the test case was not exercising the new character
flush logic.
This fixes bug 33980.
Assisted-by: LLM
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
On LoongArch64 Linux, aligning ELF load segments to Transparent Huge Page
(THP) boundaries provides consistent performance benefits for large
binaries by reducing TLB pressure and improving instruction fetch
efficiency.
Enable THP-based load segment alignment by default on LoongArch64 by
setting `glibc.elf.thp=1` during startup. Define the default THP
page size for load segment alignment on LoongArch64 as 32MB.
This allows the dynamic loader to apply THP-friendly alignment without
requiring the `glibc.elf.thp` tunable to be explicitly set.
Benchmarks
Machine: Loongson 3A6000 (LoongArch64)
Kernel: 6.18.13
CONFIG_READ_ONLY_THP_FOR_FS=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
Workload 1: building Cargo 1.93.0
Rustc: nightly-2026-02-26
Without patch With patch
instructions 3,690,358,948,176 3,690,301,774,568
cpu-cycles 4,233,025,766,760 4,035,866,635,741
itlb-misses 9,708,829,532 2,700,014,717
time elapsed 302.40 s 289.68 s
Instructions remain essentially unchanged. iTLB misses drop by about
72%, reducing CPU cycles by about 4.7% and wall time by about 4.2%.
Workload 2: building Linux kernel v7.0-rc1
LLVM: 21.1.8
Without patch With patch
instructions 14,163,739,876,387 14,169,418,598,675
cpu-cycles 19,231,890,317,741 16,851,494,928,181
itlb-misses 91,142,010,440 90,779,245
time elapsed 1022.09 s 893.22 s
Instructions remain roughly the same. iTLB misses drop from about 91B
to about 90M (roughly 99.9% reduction), reducing CPU cycles by about
12% and wall time by about 12.6%.
Reviewed-by: caiyinyu <caiyinyu@loongson.cn>
Signed-off-by: WANG Rui <wangrui@loongson.cn>
Mapping segments that are at least the size of a PMD huge page to
huge-page-aligned addresses helps make them eligible for Transparent
Huge Pages (THP).
This patch introduces a Linux-specific helper, `_dl_map_segment_align`,
to determine an appropriate maximum alignment for ELF load segments based
on the system THP policy. The optimization is enabled only when the glibc
tunable `glibc.elf.thp=1` is set and THP is configured to be used
unconditionally.
The optimization depends on Linux kernel support for file-backed THP,
specifically:
* `CONFIG_READ_ONLY_THP_FOR_FS` (available since Linux kernel 5.4), and
* `CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS`.
When enabled, the helper queries the default THP page size and uses it
to align sufficiently large load segments that are already properly
aligned in both virtual address and file offset (e.g., zero).
For eligible segments, the alignment is bumped to the THP page size,
which improves THP eligibility, reduces TLB pressure, and improves
performance for large objects. To avoid excessive address space padding
on systems with very large THP sizes, the alignment is capped at 32MB.
The optimization is applied only to non-writable segments, matching
typical THP usage.
Signed-off-by: WANG Rui <wangrui@loongson.cn>
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Introduce a new tunable, `glibc.elf.thp`, to control Transparent Huge
Page (THP) aware alignment of ELF loadable segments.
When set to `1`, the dynamic loader will attempt to align sufficiently
large `PT_LOAD` segments to the PMD huge page size when mapping them.
This increases the likelihood that the kernel backs these mappings with
Transparent Huge Pages.
The default value is `0`, which preserves the traditional page-sized
alignment and keeps existing behavior unchanged.
On systems without THP support, or when THP is disabled in the kernel,
enabling this tunable has no effect.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Signed-off-by: WANG Rui <wangrui@loongson.cn>
Introduce a new helper function, _dl_map_segment_align, to allow
architecture-specific adjustment of ELF load segment alignment during
object mapping.
The generic ELF loader now calls this hook when determining the maximum
segment alignment. The generic implementation is a no-op and preserves
existing behavior.
This provides a well-defined extension point for architectures that
need to adjust segment alignment policies (for example, to improve
mapping efficiency or enable platform-specific optimizations) without
embedding such logic directly in the generic loader.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Signed-off-by: WANG Rui <wangrui@loongson.cn>
The function `_dl_map_segments` is defined in `<dl-map-segments.h>`,
which provides the canonical implementation (optionally overridden
by sysdeps variants). All call sites include `<dl-map-segments.h>`
directly, so declaring `_dl_map_segments` in `dl-load.h` is unnecessary.
Keeping a static prototype in `dl-load.h` can trigger
-Wunused-function errors when the header is included by translation
units that do not include `<dl-map-segments.h>` and do not reference
`_dl_map_segments`. Since glibc builds with `-Werror`, this results
in build failures [1].
Remove the redundant declaration from `dl-load.h` to avoid these
spurious warnings and keep the declaration colocated with the
definition as intended.
[1] https://ci.linaro.org/job/tcwg_glibc_build--master-aarch64-precommit/4624/artifact/artifacts/artifacts.precommit/notify/mail-body.txt
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Signed-off-by: WANG Rui <wangrui@loongson.cn>
'struct timeval' and 'struct time_value' have different types for the
microseconds component: int and long int. Casting one to the other
leads to negative numbers not being preserved properly within the
called code.
Message-ID: <20260415180318.109742-3-mike@weatherwax.co.uk>
Malloc defines a lot of aliases which are unused, not exported and not needed.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: DJ Delorie <dj@redhat.com>
We need to keep the heading / to properly get an ENOTDIR, and set
file_name rather than change the retryname content.
Also, *result is normally used for the startdir.
Consistently use one space after catgory keyword in all 352 locales.
We adjust gen_unicode_ctype.py to emit the same format for i18n_ctype.
This makes the files more consistent for command line tooling to
manipulate.
The locales en_GB and en_IE use a date format of "%d//%m//%y",
as this is the most common shorthand format in both countries.
However the ga_IE locale does not conform to this. The format
"%d.%m.%y" is not commonly used in either the ROI or the UK,
and the forward-slash separator is the most common in both
languages when used in both countries.
This can be verified by checking the CLDR data for Irish:
https://www.unicode.org/cldr/charts/48/verify/dates/ga.html
Signed-off-by: Charlotte Mcmenamin <altronic25@protonmail.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Fix logic bug in __nss_get_default_domain that prevents
proper initialization.
Because this function is not exposed, the test case must link
against the object directly.
Bug origin commit: 64d1e08ea8
Co-authored-by: Florian Weimer <fweimer@redhat.com>
Reviewed-by: Frédéric Bérat <fberat@redhat.com>
After
commit f685e3953f9a38a41bbd0a597f9882870cee13d5
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Wed Oct 29 09:49:57 2025 +0800
elf: Don't set its DT_VERSYM entry for unversioned symbol
ld no longer assigns version index 1 to unversioned defined symbol.
For libmachuser.so, "objdump --dynamic-syms" reports:
0000dd30 w DF .text 000000f8 processor_start
instead of
0000dd30 w DF .text 000000f8 (Base) processor_start
Also allow NF == 6 for weak unversioned dynamic symbols. This fixes BZ
33650.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
Sort and put one test per line in sysdeps/unix/sysv/linux/Makefile.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
For normal numbers there is no need to issue scalbn, the fma can set
the exponend directly. Performance-wise on x86_64-linux-gnu without
multi-arch it shows a latency improvement of ~5% and throughput of %7
(and sligth more for ABIs witht tail-call optimization).
Checked on x86_64-linux-gnu and i686-linux-gnu with --disable-multi-arch.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Both `posix_spawn_file_actions_add{,f}chdir` functions are now fully
defined by POSIX-2024, this patch adds both functions as aliases of the
already existing `posix_spawn_file_actions_add{,f}chdir_np` GNU
extensions.
This makes glibc more compliant in regards to POSIX-2024.
Signed-off-by: Lucas Chollet <lucas.chollet@free.fr>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
manual/tunables.texi: update glibc.malloc.tcache_count to 16, in sync
with source code; fix a typo in glibc.mem.decorate_maps tunable
Signed-off-by: Rocket Ma <marocketbd@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch fixes a memory leak when ungetwc is used on a wide oriented stream.
The backup buffer was never freed on fclose, causing a memory leak per
ungetwc/fclose call.
The leak has two causes:
In iofclose.c, for wide streams (fp->mode > 0), _IO_new_fclose never calls
_IO_free_wbackup_area. Fixed by adding the missing call.
In wgenops.c, _IO_wdefault_finish checks fp->_IO_save_base (the narrow field,
always NULL for wide streams) instead of fp->_wide_data->_IO_save_base,
and uses a bare free() that leaves _IO_save_end and _IO_backup_base dangling.
Replace the hand-rolled cleanup with _IO_have_wbackup/_IO_free_wbackup_area,
which handles backup-mode switching and clears all three pointers.
This was independently reported by Rocket Ma [1], whose patch corrects the condition
but still uses the manual free path.
Apply the same _IO_have_backup condition in genops.c for consistency.
Tested by:
make test t=libio/tst-wbackup-leak
[1] https://patchwork.sourceware.org/project/glibc/patch/20260323171742.1039768-1-marocketbd@gmail.com/
Signed-off-by: Xiang Gao <gaoxiang@kylinos.cn>
The helpers for determining the default transparent huge page size
and THP mode are currently implemented in malloc-hugepages. However,
these interfaces are not malloc-specific and are also needed by other
subsystems (e.g. the dynamic loader for segment alignment).
Introduce a new generic hugepages abstraction and move the THP mode
detection, default THP page size probing, and hugepage configuration
helpers there. The malloc code now calls into the generic helpers
instead of duplicating the sysfs parsing.
There is no functional change. This is a pure refactoring to make
the THP detection reusable outside of malloc.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Signed-off-by: WANG Rui <wangrui@loongson.cn>
This ensures that the test does not accidentally use a name server
running on 127.0.0.1.
Tested-by: Frédéric Bérat <fberat@redhat.com>
Reviewed-by: Frédéric Bérat <fberat@redhat.com>
This patch synchronizes the glibc fts implementation with the latest
version from gnulib (as of 2026-02-16).
The primary motivation is to address limitations in the legacy glibc
implementation, most notably BZ 22944, where fts fails with an
ENAMETOOLONG error when traversing very long paths or deeply nested
directory trees. The gnulib implementation dynamically reallocates
path buffers and uses openat/fchdir optimizations, effectively
lifting the MAXPATHLEN limitation.
The gnulib implementation also added extra features, which are
used by different GNU projects (coreutils, diffutils):
* FTS_TIGHT_CYCLE_CHECK: used to enable a strict, immediate
cycle-detection algorithm during a file system traversal. This is
done internally using a hash table: every time the traversal enters
a directory, it records the directory's device and inode (dev/ino)
pair in the hash table, and before entering any directory, fts
checks the hash table.
* FTS_CWDFD: instead of actually changing the process's current
working directory, it maintains a virtual current working directory
using file descriptors. The file descriptor is store at the
fts_cwd_fd field and all subsequent file operations are performed
relative to this file descriptor using *at functions.
* FTS_DEFER_STAT: performance-oriented flag that instructs the file
tree traversal engine to delay fetching file metadata. When the
flag is used, fts skips the immediate stat call. Instead, it marks
the entry with a special internal state (FTS_NSOK and
FTS_STAT_REQUIRED). The actual stat call is pushed down the line
and executed by fts_read right before the application actually
accesses the entry.
* FTS_VERBATIM: fts_open accept and use the path strings exactly as
they were provided in the arguments array without slash trimming.
* FTS_MOUNT: it restrict the file tree walk to a single file system.
Hopefully,it would allow some GNU projects to use the glibc
implementation instead of pulling the gnulib one.
It requires some changes to keep compatibility, compared to gnulib:
* The new required fields are added at the end of FTS structure, and
the new FTS flags are adjusted to avoid change FTS_NAMEONLY/FTS_STOP
(even though they are marked as private).
* The FTSENT uses a flexible array (fts_name), so two adjustments are
required: the two new members (fts_fts and fts_dirp) are place
*before* the struct and the fts_statp is now always allocated and
accounted (the gnulib implementation uses an alwyas allocated member).
Checked on x86_64-linux-gnu and i686-linux-gnu.
It follows the C2y N3367 proposed interface, along with some tests
imported from gnulib (and adapted to glibc libsupport).
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
An interrupted RPC call can return EINTR whilst the RPC is still in
progress on the server. Some RPC calls have permanent consequences
(eg. a write() to append data to a file) but a caller seeing EINTR
should expect that no state has changed. The signal thread now stores
the server's reply (which it already waited for) as the interrupted
thread's reply.
Message-ID: <20260401194948.90428-3-mike@weatherwax.co.uk>
MSG_EXAMINE has been broadened to allow the signal thread (for
example) to access additional arguments that are passed to
interruptible RPCs in other threads. All architecture specific
variants of intr-msg.h now comply with the revised interface and the
single user of MSG_EXAMINE (report-wait.c) adjusted accordingly.
Message-ID: <20260401194948.90428-2-mike@weatherwax.co.uk>
Update the hugetlb tunable default in elf/dl-tunables.c so it is shown as 1
with /lib/ld-linux-aarch64.so.1 --list-tunables.
Move the intitialization of thp_mode/thp_pagesize to do_set_hugetlb() and
avoid accessing /sys/kernel/mm if DEFAULT_THP_PAGESIZE > 0. Switch off THP if
glibc.malloc.hugetlb=0 is used - this behaves as if DEFAULT_THP_PAGESIZE==0.
Fix the --list-tunables testcase.
Reviewed-by: DJ Delorie <dj@redhat.com>
The current implementation of ftw relies on recursion to traverse
directories (ftw_dir calls process_entry, which calls ftw_dir). In deep
directory trees, this could lead to a stack overflow (as demonstrated by
the new tst-nftw-bz33882.c test).
This patch refactors ftw to use an explicit, heap-allocated stack to
manage directory traversal:
* The 'struct ftw_frame' encapsulates the state of a single directory
level (directory stream, stat buffer, previous base offset, and
current state).
* The ftw_dir is rewritten to use a loop instead of recursion and
an iterative loop to enable immediate state transitions without
function call overhead.
The patch also cleans up some unused definitions and assumptions (e.g.,
free-clobbering errno) and fixes a UB when handling the ftw callback.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: DJ Delorie <dj@redhat.com>
The CORE-MATH e756933f improved the error bound in the fast path for
x_0 <= x < 1/4, along with a formal proof [1].
Checked on x86_64-linux-gnu, i686-linux-gnu, aaarch64-linux-gnu,
and arm-linux-gnueabihf.
[1] https://core-math.gitlabpages.inria.fr/sinh.pdf
Introduced a synthetic architecture preference flag (Prefer_EVEX512)
and enabled it for AMD Zen5 (CPUID Family 0x1A) when AVX-512 is supported.
This flag modifies IFUNC dispatch to prefer 512-bit EVEX variants over
256-bit EVEX variants for string and memory functions on Zen5 processors,
leveraging their native 512-bit execution units for improved throughput.
When Prefer_EVEX512 is set, the dispatcher selects evex512 implementations;
otherwise, it falls back to evex (256-bit) variants.
The implementation updates the IFUNC selection logic in ifunc-avx2.h and
ifunc-evex.h to check for the Prefer_EVEX512 flag before dispatching to
EVEX512 implementations. This change affects six string/memory functions:
- strchr
- strlen
- strnlen
- strrchr
- strchrnul
- memchr
Benchmarks conducted on AMD Zen5 hardware demonstrate significant
performance improvements across all affected functions:
Function Baseline Patched Avg Avg Avg Max
Variant Variant Baseline Patched Change Improve
(ns) (ns) % %
------------+----------+----------+-----------+----------+--------+--------
STRCHR evex evex512 16.408 12.293 25.08% 37.69%
STRLEN evex evex512 16.862 11.436 32.18% 56.74%
STRNLEN evex evex512 18.493 11.762 36.40% 64.40%
STRRCHR evex evex512 15.154 10.874 28.24% 44.38%
STRCHRNUL evex evex512 16.464 12.605 23.44% 45.56%
MEMCHR evex evex512 9.984 8.268 17.19% 39.99%
Additionally, a tunable option (glibc.cpu.x86_cpu_features.preferred)
is provided to allow runtime control of the Prefer_EVEX512 flag for testing
and compatibility.
Reviewed-by: Ganesh Gopalasubramanian <Ganesh.Gopalasubramanian@amd.com>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The new test from 19781c2221 triggers a failure on i686:
testing float (without inline functions)
Failure: lgamma (0x3.12be38p+120): errno set to 0, expected 34 (ERANGE)
Failure: lgamma_upward (0x3.12be38p+120): errno set to 0, expected 34 (ERANGE)
Use math_narrow_eval on the multiplication to force the expected
precision.
Checked on i686-linux-gnu.
This is similar to original CORE-MATH code and why the function
exists.
Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu,
and arm-linux-gnueabihf.
The processed hostname in getanswer_ptr should be correctly checked to
avoid invalid characters from being allowed, including shell
metacharacters. It is a security issue to fail to check the returned
hostname for validity.
A regression test is added for invalid metacharacters and other cases
of invalid or valid characters.
No regressions on x86_64-linux-gnu.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Some distributions ban the /usr/bin/python path in their build
systems due to the ambiguity of whether it refers to Python 2 or
Python 3. Python 2 has been out of support for many years, and
glibc has required Python 3 at build time for a while. So it seems
safe to switch the remaining scripts over to /usr/bin/python3.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The libc_feupdateenv_test macro is supposed to trap when the trap for a
previously held exception is enabled. But
libc_feupdateenv_test_loongarch wasn't doing it properly: the comment
claims "setting of the cause bits" would cause "the hardware to generate
the exception" but that's simply not true for the LoongArch movgr2fcsr
instruction.
To fix the issue, we need to call __feraiseexcept in case a held exception
is enabled to trap.
Reviewed-by: caiyinyu <caiyinyu@loongson.cn>
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
tst-cancel31 fail on la32 qemu-system with a single-core
system sometimes.
IF the test and a infinite loop run on a same x86_64 core,
the test also fail sometimes.
taskset -c 0 make test t=nptl/tst-cancel31
taskset -c 0 ./a.out (a.out is a infinite loop)
After writeopener thread opens the file, it may switch to
main thread and find redundant files.
pthread_cancel and pthread_join writeopener thread
before support_descriptors_check.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The answer section boundary was previously ignored, and the code in
getanswer_ptr would iterate past the last resource record, but not
beyond the end of the returned data. This could lead to subsequent data
being interpreted as answer records, thus violating the DNS
specification. Such resource records could be maliciously crafted and
hidden from other tooling, but processed by the glibc stub resolver and
acted upon by the application. While we trust the data returned by the
configured recursive resolvers, we should not trust its format and
should validate it as required. It is a security issue to incorrectly
process the DNS protocol.
A regression test is added for response section crossing.
No regressions on x86_64-linux-gnu.
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
Explain the security issue and set the context for the vulnerability to
help downstreams get a better understanding of the issue.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Explain the security issue and set the context for the vulnerability to
help downstreams get a better understanding of the issue.
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
The comment explaining the reason to clear CAUSE does not make any
sense: it says the next "CTC" instruction would raise the FP exception
of which both the CAUSE and ENABLE bits are set, but LoongArch does not
have the CTC instruction. LoongArch has the movgr2fcsr instruction but
movgr2fcsr never raises any FP exception, different from the MIPS CTC
instruction.
So we don't really need to care CAUSE at all.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
This patch from Adhemerval sets up the ifunc redirections so that we
resolve memcpy to memcpy_generic in early startup. This avoids infinite
recursion for memcpy calls before the loader is fully initialized.
Tested-by: Jeff Law <jeffrey.law@oss.qualcomm.com>
It removes some unnecessary corner-case checks and uses a slightly
different binary algorithm for the hard-case database binary search.
Checked on aarch64-linux-gnu, arm-linux-gnueabihf,
powerpc64le-linux-gnu, i686-linux-gnu, and x86_64-linux-gnu.
It adds a minor optimization on fast path.
Checked on aarch64-linux-gnu, arm-linux-gnueabihf,
powerpc64le-linux-gnu, i686-linux-gnu, and x86_64-linux-gnu.
Enable adding known failures to allowed-failures.txt and ignore failures
in case they are in the list. In case the allowed-failures.txt does not
exist, all failures lead to a failed status as before.
When the file is present, failures of listed tests are ignored and reported
on stdout. If tests not in the allowed list fail, summarize-tests exits with
status 1 and reports the failing tests.
The expected format of allowed-failures.txt file is:
<test_name> # <comment>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The libgcc implementations of __builtin_clzl/__builtin_ctzl may require
access to additional data that is not marked as hidden, which could
introduce additional GOT indirection and necessitate RELATIVE relocs.
And the RELATIVE reloc is an issue if the code is used during static-pie
startup before self-relocation (for instance, during an assert).
For this case, the ABI can add a string-bitops.h header that defines
HAVE_BITOPTS_WORKING to 0. A configure check for this issue is tricky
because it requires linking against the standard libraries, which
create many RELATIVE relocations and complicate filtering those that
might be created by the builtins.
The fallback is disabled by default, so no target is affected.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Remove the prefer_sve_ifuncs CPU feature since it was intended for older
kernels. Current distros all use modern Linux kernels with improved support
for SVE save/restore, making this check redundant.
Reviewed-by: Yury Khrustalev <yury.khrustalev@arm.com>
First off, apologies for my misunderstanding on how madvise(MADV_HUGEPAGE)
works. I had the misconception that doing madvise(p, 1, MADV_HUGEPAGE) will set
VM_HUGEPAGE on the entire VMA - it does not, it will align the size to
PAGE_SIZE (4k) and then *split* the VMA. Only the first page-length of the
virtual space will VM_HUGEPAGE'd, the rest of it will stay the same.
The above is the semantics for all madvise() calls - which makes sense from a
UABI perspective. madvise() should do the proposed thing to only the length
(page-aligned) which it was asked to do, doing any more than that is not
something the user is expecting.
Commit 6e8f32d39a tries to optimize around the madvise() call by determining
whether the VMA got madvise'd before. This will work for most cases except
the following: if check_may_shrink_heap() is true, shrink_heap() re-maps the
shrunk portion, giving us a new VMA altogether. That VMA won't have the
VM_HUGEPAGE flag.
Reverting this commit, we will again mark the new VMA with VM_HUGEPAGE, and
the kernel will merge the two into a single VMA marked with VM_HUGEPAGE.
This may be the only case where we lose VM_HUGEPAGE, and we could micro-optimize
by extending the current if-condition with !check_may_shrink_heap. But let us
not do this - this is very difficult to reason about, and I am soon going
to propose mmap(MAP_HUGEPAGE) in Linux to do away with all these workarounds.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The inclusion of generic tanh implementation without undefining the
libm_alias_double (to provide the __tanh_sse2 implementation) makes
the exported tanh symbol pointing to SSE2 variant.
Reviewed-by: DJ Delorie <dj@redhat.com>
Common data definitions are moved to e_coshsinh_data, cosh only
data is moved to e_cosh_data, sinh to e_sinh_data, and tanh to
e_tanh_data.
Reviewed-by: DJ Delorie <dj@redhat.com>
The last uses of PTHREAD_IN_LIBC is where it should have been
__PTHREAD_NPTL/HTL. The latter was not conveniently available everywhere.
Defining it from config.h makes things simpler.
The 570c46d36b make libgcc_s to be defined for have-cc-with-libunwind=noi
(default for gcc builds) without taking into consideration that the compiler
can link against -lgcc_s (defined by have-libgcc_s).
Checked with a build-many-glibc.py for x86_64-linux-gnu.
The Linux implementation of __check_pf retrieves interface data via
make_request, which queries the kernel via netlink. The IFA_ADDRESS
received from the kernel's RTM_NEWADDR netlink message is (a)
type-punned via pointer-casting leading to strict aliasing violations,
and (b) dereferenced assuming that it is non-NULL.
This commit removes the strict-aliasing violations using memcpy, and
adds an assert that the address is indeed non-NULL before dereferencing
it.
Reported-by: Siteshwar Vashisht <svashisht@redhat.com>
Reviewed-by: Sam James <sam@gentoo.org>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
GCC warns about this with -Wshift-negative-value:
In file included from ../sysdeps/x86/cpu-features.c:24:
../sysdeps/x86/dl-cacheinfo.h: In function ‘get_common_cache_info’:
../sysdeps/x86/dl-cacheinfo.h:913:45: warning: left shift of negative value [-Wshift-negative-value]
913 | count_mask = ~(-1 << (count_mask + 1));
| ^~
../sysdeps/x86/dl-cacheinfo.h:930:45: warning: left shift of negative value [-Wshift-negative-value]
930 | count_mask = ~(-1 << (count_mask + 1));
| ^~
This is because C23 § 6.5.8 specifies that this is undefined behavior.
We can cast it to unsigned which would be equivelent to UINT_MAX.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The 'unwind-link' facility allows glibc to support thread cancellation
and exit (pthread_cancel, pthread_exiti, backtrace) by dynamically
loading the unwind library at runtime, preventing a hard dependency on
libgcc_s within libc.so.
When building with libunwind (for clang/LLVM toolchains [1]), two
assumptions in the existing code break:
1. The runtime library is libunwind.so instead of libgcc_s.so.
2. libgcc relies on __gcc_personality_v0 to handle unwinding mechanics.
libunwind exposes the standard '_Unwind_*' accessors directly.
This patch adapts `unwind-link` to handle both environments based on
the HAVE_CC_WITH_LIBUNWIND configuration:
* The UNWIND_SONAME macro now selects between LIBGCC_S_SO and
LIBUNWIND_SO.
* For libgcc, it continues to resolve `__gcc_personality_v0`.
* For libunwind, it instead resolves the standard
_Unwind_GetLanguageSpecificData, _Unwind_SetGR, _Unwind_SetIP,
and _Unwind_GetRegionStart helpers.
* unwind-resume.c is updated to implement wrappers for these
accessors that forward calls to the dynamically loaded function
pointers, effectively shimming the unwinder.
Tests and Makefiles are updated to link against `$(libunwind)` where
appropriate.
Reviewed-by: Sam James <sam@gentoo.org>
[1] https://github.com/libunwind/libunwind
The `have-cc-with-libunwind` check (and its corresponding macro
HAVE_CC_WITH_LIBUNWIND) was historically specific to IA64, intended
to supplement libgcc with libunwind. Since this logic is unused in
current GCC configurations, this patch repurposes it to support
clang-based toolchains that utilize LLVM's libunwind instead of
libgcc_s.
The configure script now detects if the compiler natively supports
unwinding via `-lunwind`.
Additionally, when this mode is enabled, `-lclang_rt.builtins` is
explicitly added to the `libgcc_eh` definition. This is necessary
because `links-dso-program` otherwise fails to link due to a missing
`__gcc_personality_v0` symbol. It appears that clang does not
automatically link the builtins providing this personality routine
when `rlink-path` is actively used during the build.
Reviewed-by: Sam James <sam@gentoo.org>
Historically, the build system has hardcoded references to `-lgcc` and
`-lgcc_eh`, explicitly assuming the use of the GCC runtime. This
prevents building glibc with alternative toolchains, specifically clang
configured with `--rtlib=compiler-rt`, where these libraries are
replaced by `libclang_rt.builtins`.
This patch introduces a mechanism to dynamically detect the compiler's
underlying runtime library.
The logic works as follows:
1. It queries the compiler using `-print-libgcc-file-name`.
2. It parses the output path to determine if `libgcc` or `compiler-rt`
is in use.
3. Based on this detection, it parametrizes the build variables for
the static runtime and exception handling libraries (replacing
hardcoded `-lgcc` and `-lgcc_eh`).
This ensures that the build system correctly links against the active
compiler runtime—whether it is the traditional libgcc or LLVM's
compiler-rt—without requiring manual overrides.
Reviewed-by: Sam James <sam@gentoo.org>
Make XOPEN2K24 checks the same as XOPEN2K8 using the following command:
$ find conform -name '*.h-data' | xargs sed -i \
-e 's| !defined XOPEN2K8| !defined XOPEN2K8 \&\& !defined XOPEN2K24|g' \
-e 's| defined XOPEN2K8| defined XOPEN2K8 \|\| defined XOPEN2K24|g' \
-e 's|ifdef XOPEN2K8|if defined XOPEN2K8 \|\| defined XOPEN2K24|g' \
-e 's|ifndef XOPEN2K8|if !defined XOPEN2K8 \&\& !defined XOPEN2K24|g'
Reviewed-by: Yury Khrustalev <yury.khrustalev@arm.com>
Make POSIX.1-2024 checks the same as POSIX.1-2008 using the following
command:
$ find conform -name '*.h-data' | xargs sed -i \
-e 's| !defined POSIX2008| !defined POSIX2008 \&\& !defined POSIX2024|g' \
-e 's| defined POSIX2008| defined POSIX2008 \|\| defined POSIX2024|g' \
-e 's|ifdef POSIX2008|if defined POSIX2008 \|\| defined POSIX2024|g' \
-e 's|ifndef POSIX2008|if !defined POSIX2008 \&\& !defined POSIX2024|g'
Reviewed-by: Yury Khrustalev <yury.khrustalev@arm.com>
Cleanup warnings - malloc builds with -Os and -Og without needing any
complex warning avoidance defines.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
All branches already have a fix, so this is mainly for distributions
that may have cherry-picked the SSE2 memcmp implementation.
Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
In LoongArch, fcsr1 is the alias of enables field in fcsr0, fscr3 is the
alias of RM field in fscr0. This patch use fcsr1 and fcsr3 register to
optimize fedisableexcept, feenableexcept, fegetexcept, fegetround,
fesetround, get_rounding_mode functions, which could reduce the
additional andi instruction.
The LLVM compiler-rt builtins library does not currently provide an
implementation for __sfp_handle_exceptions. On x86_64, this causes
unresolved symbol errors when building glibc in environments that
exclude libgcc.
This patch implements __sfp_handle_exceptions specifically for x86_64,
bridging the gap for non-GNU compiler runtimes.
The implementation is used conditionally, only if the compiler does
not already provide the symbol.
NB: the implementation is based on libgcc and raises bosh SSE and i387
exceptions (different that the one from 460ee50de0)
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
PR118629 [1] resolved issue with usage of __PRETTY_FUNCTION__
(to which assert expands) inside unevaluated context for GCC 14.3.
This affects only versions 14.1 and 14.2, as -std=c++26 option is
supported since 14.1.
clang supports above snippet for all version that supports --std=c++26
flag (since 17.0.1).
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118629
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch addresses Bug 33935 - _IO_wfile_doallocate not linked correctly
when linking glibc statically.
https://sourceware.org/bugzilla/show_bug.cgi?id=33935
The function _IO_wfile_doallocate has been added with pragma weak in vtable.c,
while it is the only one symbol contained in wfiledoalloc.c,
and has not been directly called in libio.
In static binaries the true function symbol _IO_wfile_doallocate may not
be correctly linked when linking glibc with cases contains wchar functions,
but the weak symbol in vtable is linked instead,
and cause segmentation fault when running.
This patch fixes this with similar way to symbol _IO_file_doallocate,
that add libio_static_fn_required(_IO_wfile_doallocate) in wgenops.c
to make _IO_wfile_doallocate always link in static binaries.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Use generic stdc_bit_width to safely adapt to input types. Move rounding up of
alignments that are not powers of 2 to __libc_memalign. Simplify alignment
handling of aligned_alloc and __posix_memalign. Add a testcase for non-power
of 2 memalign and fix malloc-debug.
Reviewed-by: DJ Delorie <dj@redhat.com>
Adds support for excluding specific categories from `LD_DEBUG` output.
The `LD_DEBUG` environment variable now accepts category names prefixed
with a dash (`-`) to disable their debugging output. This allows users
to enable broad categories (e.g., `all`) while suppressing verbose or
irrelevant information from specific sub-categories (e.g., `-tls`).
The `process_dl_debug` function in `rtld.c` has been updated to parse
these exclusion options and unset the corresponding bits in
`GLRO(dl_debug_mask)`. The `LD_DEBUG=help` output has also been updated
to document this new functionality. A new test `tst-dl-debug-exclude.sh`
is added to verify the correct behavior of category exclusion.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This commit introduces extensive debug logging for thread-local storage
(TLS) operations within the dynamic linker. When `LD_DEBUG=tls` is
enabled, messages are printed for:
- TLS module assignment and release.
- DTV (Dynamic Thread Vector) resizing events.
- TLS block allocations and deallocations.
- `__tls_get_addr` slow path events (DTV updates, lazy allocations, and
static TLS usage).
The log format is standardized to use a "tls: " prefix and identifies
modules using the "modid %lu" convention. To aid in debugging
multithreaded applications, thread-specific logs include the Thread
Control Block (TCB) address to identify the context of the operation.
A new test module `tst-tls-debug-mod.c` and a corresponding shell script
`tst-tls-debug-recursive.sh` have been added. Additionally, the existing
`tst-dl-debug-tid` NPTL test has been updated to verify these TLS debug
messages in a multithreaded context.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
We need to tie the fast-path read with the store, to make sure that when
fast-reading 1, we see all the effects performed by the init routine.
(and we don't need a full barrier, only an acquire/release pair is
needed)
Reported-by: Brent Baccala <cosine@freesoft.org> 's Claude assistant
In case e.g. some atexit() handlers expect all threads to have finished
their side effects.
Reported-by: Brent Baccala <cosine@freesoft.org> 's Claude assistant
Without taking _hurd_siglock, we could be missing the addition of a global
preemptor.
Reported-by: Brent Baccala <cosine@freesoft.org> 's Claude assistant
There is a conditional inclusion of <linux/mount.h> earlier in the file.
If that defines the macros, do not redefine them. This addresses build
problems as the token sequence used by the UAPI macro definitions
changes between Linux versions.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
On AArch64 malloc always checks /sys/kernel/mm/transparent_hugepage/enabled to
set the THP mode. However this check is quite expensive and the file may not
be accessible in containers. If DEFAULT_THP_PAGESIZE is non-zero, use
malloc_thp_mode_madvise so that we take advantage of THP in all cases. Since
madvise is a fast systemcall, it adds only a small overhead compared to the
cost of mmap and populating the pages.
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
In case the rwlock is unlocked right before we time out, we will have been
given ownership, so we shouldn't time out.
Reported-by: Brent Baccala <cosine@freesoft.org> 's Claude assistant
read/write etc. shall be signal-safe, and take cancel_lock, so we have to
defer signal delivery while holding cancel_lock.
Reported-by: Brent Baccala <cosine@freesoft.org> 's Claude assistant
It is required to test "search ." in /etc/resolv.conf files. The
default is to override the search path isolate from unexpected
settings in the test execution environment.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Change the mask to 48 to support len==64. The second memory store now accesses
offset 32, whereas the third one accesses offset 16. As a result performance
for len==64 almost doubles.
Currently malloc has various assumptions, some documented, some implicit.
Add a few asserts to check the most fundamental assumptions using verify().
Remove some odd #define void.
Reviewed-by: Paul Eggert <eggert@cs.ucla.edu>
On some emulated targets sleep may result in inconsistent wait
times which will lead to the failure of the tst-chmod test.
To account for this we use the CLOCK_PROCESS_CPUTIME_ID clock ID
while also consuming CPU time by repeatedly calling clock_gettime.
Reviewed-by: DJ Delorie <dj@redhat.com>
C++26 changes assert into a variadic macro to support using
assignment-expressions that would be interpreted as multiple macro
arguments, in particular one containing:
* template parameter lists: func<int, float>()
* calls to overloaded operator[] that accepts multiple arguments: arr[1, 2]
this is C++23 feature, see libstdc++ PR/119855 [1]
* lambdas with explicit captures: [x, y] { ... }
The new expansion in form:
(__VA_ARGS__) ? void (1 ? 1 : bool (__VA_ARGS__))
: __assert_fail (...)
Has the following properties:
* Use of (__VA_ARGS__) ? ... : ..., requires that __VA_ARGS__
is contextually convertible to bool. This means that enumerators
of scoped enumeration are no longer accepted (they are only
explicitly convertible). Thus this patch address the glibc PR/27276 [2].
* Nested ternary 1 ? 1 : bool (__VA_ARGS__) guarantees that
expression expanded from __VA_ARGS__ is not evaluated twice.
This is used instead of unevaluated context (like sizeof...)
to support C++ expressions that are not allowed in unevaluated
context (lambdas until C++20, co_await, co_yield).
* bool (__VA_ARGS__) is ill-formed if __VA_ARGS__ expands to
multiple arguments: assert(1, 2)
* bool (__VA_ARGS__) also triggers warnings when __VA_ARGS__
expands to x = 1: assert(x = 1)
To guarantee that the code snippets from assert/test-assert-c++-variadic.cc,
are actually checked for validity, we need to compile this test in C++26
(-std=c++26) mode. To achieve that, this patch compiles the file with
test-config-cxxflags-stdcxx26 variable as additional flag, that is set to
-std=c++26 if $(TEST_CXX) executable supports that flag, and empty otherwise.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119855
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=27276
Co-authored-by: Tomasz Kamiński <tkaminsk@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It speeds the fast-path for |x|<0.25. The CORE-MATH muldd is the
same as muldd2 from glibc ddcoremath.h.
Checked on aarch64-linux-gnu, arm-linux-gnueabihf,
powerpc64le-linux-gnu, i686-linux-gnu, and x86_64-linux-gnu.
Reviewed-by: Paul Zimmermann <Paul.Zimmermann@inria.fr>
Since d2e0491883 ("Single threaded stdio optimization")
we are supposed to call _IO_enable_locks when creating the first thread,
but that commit missed doing it for htl.
The negative sigcodes are reserved for SI_* values, we need to keep them
negative when extending to exc_subcode's long type.
This fixes the comparison in HURD_PREEMPT_SIGNAL_P for the signal preemptor
for setitimer, thus fixing considering it.it_interval.
Reported-by: David Yang <mmyangfl@gmail.com>
Vectorise SVE and AdvSIMD special-case handling for inverse
hyperbolic functions (acosh, asinh, atanh).
General-case improvements yield an average 11% speedup, with
peak gains of up to 80%.
For benchmarking I used Neoverse V2 with GCC@15.
This patch vectorises remaining special cases and optimises some
fast path performance for single and double precision exp, SVE and
AdvSIMD.
Moves most special case functions to header files to minimise code size.
Uses NOINLINE in main case where half width alias is used to minimise
codegen.
Special case vectorisation performance increase of average 8x to
greatest 9.5x.
Special case improvements performance increase average 15% speed
improvement to greatest 40%.
Some fast path gains during rework of files. Fastest notable increase
in exp2m1 AdvSIMD double precision of 26% improvement. Most fast
paths improved by 5-10%. 8 unchanged. No regressions.
Benchmarked on Neoverse V2 with GCC@15
This patch vectorises scalar fallbacks for SVE logB(f) functions.
Special case performance increase of around 3x speedup for double
and 5x speedup for single precision.
Some fast path gains during rework of files. Most fast paths improved
by 2-3%. 2 unchanged. No regressions.
Benchmarked on Neoverse V2 with GCC@15.
This patch vectorises special cases and optimises some fast path
performance for single and double precision hyperbolics, sve and
advsimd.
Special case performance increase of average 4x to greatest 10x.
Some fast path gains during rework of files. Fastest notable increase
in sinh advsimd double precision of 2x. Most fast paths improved by
5-10%.
Benchmarked on Neoverse V2 with GCC@15.
* manual/memory.texi (Portable Allocation):
New section, split off from Malloc Examples.
Say that almost every system follows glibc's example
in having successful malloc (0) return non-null;
AIX is the only exception nowadays.
Document fundamental alignment portability.
Have examples match the new text, and use NULL rather than 0.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The libio/bits/stdio2-decl.h only defined the prototypes for
__vasprintf_chk and __vfprintf_chk for __USE_FORTIFY_LEVEL > 1.
Also defined them for the internal header regardless.
Checked with a build with --enable-fortify-source=1 and
--enable-fortify-source=2 for all afftected ABIs.
MIPS Linux has SIGRTMAX=127, thus the wait status 0x7f means the program
is terminated by SIGRTMAX, not stopped.
This cannot happen on other ports so make a special version of
waitstatus.h for MIPS to avoid adding redundant calculation to others.
I cannot find a way to use status only once in the expression, so use
inline functions instead of macros to avoid double-evaluating status.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The initialization process of libc.so calls mmap() several times and the
kernel may lay the maps into the gap. If all pages in the gap are
occupied, the test would not be able to find the gap with mmap() and the
test would fail.
The failure reproduces most frequently on LoongArch because with the
commonly used page size (16 KiB) the gap only contains 4 pages and the
probability they are all occupied is not near to zero.
With the changes in the patch, a test run may output:
info: ld.so link map is not contiguous
info: object "/dev/zero" found at 0x7ffff1fe0000 - 0x7ffff1fe4000
info: anonymous mapping found at 0x7ffff1fe4000 - 0x7ffff1fec000
Also take the chance to fix a mistake in the "object found at" message
which has puzzled me during the initial debug session.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
A sub-test of tst-rseq is to validate the return code and errno of the
rseq syscall when attempting to register the exact same rseq area as was
done in the dynamic loader.
This involves finding the rseq area address by adding the
'__rseq_offset' to the thread pointer and calculating the area size from
the AT_RSEQ_FEATURE_SIZE auxiliary vector. However the test currently
calculates the size of the rseq area allocation in the TLS block which
must be a multiple of AT_RSEQ_ALIGN.
Up until now that happened to be the same value since the feature size
and alignment exposed by the kernel were below the minimum ABI size of
32. Starting with Linux 7.0 the feature size has reached 33 while the
alignment is now 64.
This results in the test trying to re-register the rseq area with a
different size and thus not getting the expected errno value.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
The canonical lock ordering for stream list processing is
locking list_all_lock first, then individual streams as needed.
The fclose implementation reversed that, and the freopen
implementation performed list operations under the reverse order,
too.
Unlinking in fclose was already unconditional, and the early unlinking
looks unnecessary: _IO_file_close_it would call it even for
!_IO_IS_FILEBUF streams.
There is still a remaining concurrency defect because
_IO_new_file_init_internal links in the stream before it is
fully initialized, and it is not locked at this point.
Reviewed-by: Arjun Shankar <arjun@redhat.com>
Also replace the loop with strlen And remove
-fno-tree-loop-distribute-patterns usage.
It requires redirect the strlen to the baseline implementation
for x86_64, aarch64, and loongarch64.
Checked on x86_64-linux-gnu{-v2,v3} and aarch64-linux-gnu with
both gcc-15 and clang-21.
Reviewed-by: DJ Delorie <dj@redhat.com>
* posix/execvpe.c (__execvpe_common): Rather than error out
with ENAMETOOLONG, just ignore and try the next path.
Note we know the FILE length is <= NAME_MAX, so the ENAMETOOLONG
almost certainly pertains to the current $PATH entry.
* posix/tst-execvpe7.c: A new test based on tst-execvp3.c.
* posix/Makefile: Reference the new test.
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
__unused is often defined to __attribute__((unused)) in BSD
sources and furthermore libstdc++ testsuite uses it as a macro
to verify libstdc++ headers don't use __unused identifiers.
In ~2012 glibc headers have been cleaned up, but some new
uses of __unused have reappeared (s390 fenv.h already many
years ago, the rest last November).
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Check that GCS is locked properly based on the value of the
glibc.cpu.aarch64_gcs tunable.
Test tst-gcs-execv checks that a child process can be spawned correctly
when GCS is locked for the parent process.
Test tst-gcs-fork checks that if GCS is not locked for the parent
process, the forked child can disable GCS.
Tests tst-gcs-lock and tst-gcs-lock-static check that GCS is locked
for dynamic and static executables when run with aarch64_gcs=1.
Tests tst-gcs-unlock and tst-gcs-unlock-static check that GCS is not
locked for dynamic and static executables when run with aarch64_gcs=0.
Test tst-gcs-lock-ptrace checks via ptrace that when GCS is locked,
all GCS features are locked.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
If GCS is enabled (see tunable glibc.cpu.aarch64_gcs), we lock all GCS
operations (including status, write on shadow stack, and push to shadow
stack) unless OPTIONAL policy is used.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Some BTI tests in the sysdeps/unix/sysv/linux/aarch64 directory use
test shared objects via dlopen. Due to lack of direct makefile level
dependencies on these modules these tests could be run before the
required .so files would be created. This could lead to flaky test
results when running make check with -j flag. This commit fixes it.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
alarm() and restart_itimer() can attempt to acquire _hurd_siglock and
_hurd_itimer_lock in opposite sequence resulting in occasional
deadlock. Rearranged to always acquire the locks in the same sequence
with a new pre-condition that setitimer_locked() must be called with
both locks already acquired.
Message-ID: <20260214091715.157471-2-mike@weatherwax.co.uk>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
This avoids a null pointer dereference in the
nss_database_check_reload_and_get function, and assertion failures.
Reviewed-by: Sam James <sam@gentoo.org>
Most importantly, if getwpuid_r fails, it does not make sense to retry
via utmp because the user ID obtained from there is less reliable than
the one from /proc/self/loginuid.
Reviewed-by: Sam James <sam@gentoo.org>
The initialized field in struct nss_database_data is rather confusing
because it is not used by the regular NSS code, only by the fork
state synchronization code. Introduce a separate type and place
the initialized field there.
Reviewed-by: Sam James <sam@gentoo.org>
The innetgr tests are similar to a downstream test for rhbz#1054846.
This seems to be the first tests of this function. The getnetgrent
tests are new, too.
Reviewed-by: DJ Delorie <dj@redhat.com>
This is the minimal set of changes to get the upcoming test to pass.
The TTL extension logic is somewhat iffy. There is a trade-off here:
correct operation under the DNS specification (no TTL extensions), or
reducing loading the infrastructure if TRY_AGAIN is the result of
overload from this client.
Reviewed-by: DJ Delorie <dj@redhat.com>
This change is largely auto-generated. The function implementations
are mechanical and use the glibc-specific support framework, so this
should be low-risk and therefore acceptable.
The struct etherent type is currently internal-only (although it
can be used by NSS modules), which is why it is not included here.
Reviewed-by: DJ Delorie <dj@redhat.com>
Move <netdb.h> includes into the implementation files. Use const
where appropriate. Introduce support_check_nss and use it to
implement the check_* functions.
Reviewed-by: DJ Delorie <dj@redhat.com>
Including sys/mount.h should not implicitly include fcntl.h
as that causes namespace pollution and conflicts with kernel
headers. It only needs O_CLOEXEC for OPEN_TREE_CLOEXEC
(although it shouldn't need that, but it's defined that way)
so we provide that define (via a private version) separately.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Tested-by: Florian Weimer <fweimer@redhat.com>
Calls to mach_msg_trap() that return MACH_SEND_INTERRUPTED modify the message header. A subsequent attempt at sending the message can return EINTR for handling by the caller. Mig generated code (expecting the message header to be unaltered) now fails assertion in __mig_dealloc_reply_port(). Fixed by restoring the altered message header content before reattempting RPC message delivery.
Message-ID: <20260209204213.91782-2-mike@weatherwax.co.uk>
Compiling gcc with -Werror=strict-aliasing exposed a type punning
issue in dl-fptr.c. It does a number of compare and swap operations
to atomically exchange function pointers, etc. The PTR argument
is dereferenced to determine the type of the objects to exchange.
Casting the type of the PTR argument to a different type will
result in in an error with -Werror=strict-aliasing. For example,
a `(ElfW(Addr) *' pointer is not strictly equivalent to a
`struct fdesc *' pointer.
Fix this by removing the casts from the COMPARE_AND_SWAP PTR
arguments and adjusting the type of the OLD and NEW arguments
to match the dereferenced PTR type.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Replace the 64-bit zero idiom with the 32-bit form. In 64-bit mode,
zeroing the lower 32 bits of a GPR implicitly clears the entire
register. The 32-bit encoding is one byte shorter while preserving
identical semantics.
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Now that fastbins have been removed, there is no need to add chunks
to tcache during an unsorted scan. Small blocks can only be added
to unsorted as a result of a remainder chunk split off a larger block,
so there is no point in checking for additional chunks to place in
tcache. The last remainder is checked first, and will be used if it
is large enough or an exact fit. The unsorted bin scan becomes simpler
as a result. Remove the tcache_unsorted_limit tunable and manual entries.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
No functional change. BTI tests check Linux-related functionality
and belong in the linux/aarch64 directory.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
On s390x, the two tests are failing on a lpar with linux 6.18 booted with nosmt:
FAIL: misc/tst-sched-affinity-inheritance
FAIL: nptl/tst-pthread-affinity-inheritance
Both tests were failing because they are claiming that the CPU affinity mask was
not correctly inherited in the forked process/thread.
The error already happened before forking, as the mask was set up to use
CPUs 0-14 in set_cpu_mask(). But according to e.g. lscpu or the line
"Cpus_allowed_list" in /proc/self/status, only the following CPUs were in mask at startup:
0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30
while 1, 3, 5, ... were configured, but not online.
Now the test first gets the current CPU mask at startup in do_test() and
set_cpu_mask() only selects those available CPUs. The test is now just
counting the available CPUs instead of relying on get_nprocs(). This allows
to run the test even if it was already limited via taskset.
Therefore both concrete tests now have the get_my_affinity() function. This
also allows to implement verify_my_affinity() in the common skeleton.
In order to ensure that the affinity mask is really set as expected,
verify_my_affinity() is now also called before forking a new process or
creating a new thread.
For also printing the list of mismatched CPU IDs in xor_set in
verify_my_affinity(), the argument order of CPU_ISSET_S is now fixed.
Furthermore we now keep iterating over all configured CPUs to print
the list of cpucount IDs instead of iterating over the first nproc CPUs.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
read/write etc. shall be signal-safe, and take cancel_lock, so we have to
defer signal delivery while holding cancel_lock.
Reported-by: Michael Banck <mbanck@gmx.net>
On Hygon CPUs, glibc currently relies on CPUID leaf 0x8000001D to
compute cache parameters. This works correctly on bare-metal
systems. However, under some hypervisors (e.g. QEMU with -cpu
qemu64), the maximum supported extended CPUID leaf is only
0x8000000A, and CPUID 0x8000001D is not exposed. In this case,
cache information computed via 0x8000001D is zeroed out.
This patch introduces legacy fallback of cache computation based on
CPUID 0x80000005 and 0x80000006, consistent with the AMD
implementation, to restore correct cache information under such
environments.
Signed-off-by: Jiamei Xie <xiejiamei@hygon.cn>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Handling a pending signal calls _hurd_setup_sighandler() once again
after the initial signal handling. In this case a pointer to the
previous sigcontext is available to supply the interrupted thread's
original basic state, fpu state and fpu XSTATE. The original XSTATE
was not being preserved by the pending signal but instead overwritten
with the active XSTATE. XSTATE register values modified by the
signal handling code could therefore be wrongly propogated back to
the interrupted user code.
Only enable vector math functions with -ffast-math by adding if('fastmath').
This uses a new annotation supported by GCC 16 (PR 118955). If an older
compiler is used, it will disable the math function without an error.
This fixes BZ #33226.
For copies ≤64 bytes, the implementation remains consistent with memcpy_sve.
For 65–128 bytes, it removes the 96-byte branch and reorders instructions,
improving performance by 18–32%. For >128 bytes, it aligns the destination
to a 32-byte boundary and uses Pre-indexed load/store instructions to reduce
address-update overhead.
All benchmarks report execution time (lower is better). Geomean results
(__memcpy_generic → this patch):
- bench-memcpy: 16.74 → 12.11 (28% faster)
- bench-memcpy-large: 24287 → 23302 (4% faster)
- bench-memcpy-random: 107693 → 72153 (33% faster)
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
The cast doesn't have any benefit over using a UL suffix and prevents
the macro from being used in preprocessor directives.
Reviewed-by: Arjun Shankar <arjun@redhat.com>
This verifies that LD_PROFILE is correctly ignored if LD_PROFILE_OUTPUT
is not set.
The test was initially auto-generated, then heavily edited and re-edited
for brevity and clarity. The test uses glibc-specific interfaces
(including one that did not exist at all a couple of hours ago), so
this should be unproblematic.
It allows us to write test cases in C that run tests with
dynamic linker wrapping.
The iconv test case was auto-generated. The posix_spawn usage
is mechanical, and the interface it tests is newly added in this
commit, so this should be acceptable.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
On armv7a vfpv4 tst-gnu2-tls2 fails with:
open tst-gnu2-tls2mod0.so
open tst-gnu2-tls2mod1.so
open tst-gnu2-tls2mod2.so
close tst-gnu2-tls2mod0.so
close tst-gnu2-tls2mod1.so
open tst-gnu2-tls2mod0.so
open tst-gnu2-tls2mod1.so
Didn't expect signal from child: got `Aborted'
Because AFTER_TLSDESC_CALL might clobber caller-saved registers and
the zero array might call the memset function resolution, which itself
might clobber some vector registers.
The AFTER_TLSDESC_CALL calls memset and memcmp, and both the
lazy resolution and the routines themselves can clobber the
caller-saved registes used in the tests.
Checked on arm-linux-gnueabihf (armv7-a vpfv4 / QEMU).
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Linux v6.13 introduced a new ioctl to query info from a pidfd.
The advantage of this vs. parsing /proc/ is that it works even
when procfs is not mounted. It's also a single syscall, and doesn't
need manual string parsing. Use it when available.
Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The sotruss utility printed an incomplete error message when the
ambiguous option --f was used. The message did not list the possible
matching options, making it unclear how to resolve the ambiguity.
This commit corrects the error message to report all valid alternatives.
Example after this change:
$ sotruss --f /bin/true
sotruss: option '--f' is ambiguous; possibilities: '--from' '--follow'
Try `sotruss --help' or `sotruss --usage' for more information.
This fixes BZ #25257.
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Suggested-by: Carlos Santos <casantos@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The functions are documented to behave like fmax/fmin when the
arguments have the same absolute value.
Checked on x86_64-linux-gnu, aarch64-linux-gnu, i686-linux-gnu,
arm-linux-gnueabihf, powerpc64le-linux-gnu,
riscv64-linux-gnu-rv64imafdc-lp64d, and loongarch64-linux-gnuf64.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
The C standard (at least from C99 until C23) does not require
fmin/fmax to order zeros by their sign, so glibc's previous behavior
was entirely standards-conforming. However, the standard does
recommend that zeros be ordered in a footnote, saying:
"If possible, fmax is sensitive to the sign of zero, for example
fmax(−0.0, +0.0) ideally returns +0."
As this is indeed possible (and not too complicated), implement it as
a quality-of-implementation improvement. It also remove possible
deviations between architectures, where for some architectures that
has direct mapping instruction (USE_FMA*_BUILTIN) they already do
the ordering.
Checked on x86_64-linux-gnu, aarch64-linux-gnu, i686-linux-gnu,
arm-linux-gnueabihf, powerpc64le-linux-gnu,
riscv64-linux-gnu-rv64imafdc-lp64d, and loongarch64-linux-gnuf64.
Co-authored-by: James Y Knight <jyknight@google.com>
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Using recent gcc, the generic implementation generates the same code
for normal and subnormal numbers for float/double.
For long double, the generic implementations generates slight worse
code for the fast-path. With gcc-15:
* sysdeps/x86_64/fpu/s_fmaxl.S
fldt 8(%rsp)
fldt 24(%rsp)
fucomi %st(1), %st
jp 2f
fcmovb %st(1), %st
fstp %st(1)
ret
* generic
fldt 0x8(%rsp)
fldt 0x18(%rsp)
fucomi %st(1),%st
jp 18 <__fmaxl+0x18>
fxch %st(1)
fcomi %st(1),%st
fcmovbe %st(1),%st
fstp %st(1)
ret
It could be optimized by using isgreater instead of a direct comparison
for the non unordered, but this prevents x86 to issue maxsd.
Checked on x86_64-linux-gnu.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
On x86_64, it allows the fast path (normal/subnormal inputs) to use maxsd.
With gcc-15 targetting x86_64 for fmax:
* master:
ucomisd xmm0, xmm1
jnb .L1
ucomisd xmm1, xmm0
ja .L13
[...]
.L13:
movapd xmm0, xmm1
.L1:
ret
* patch;
ucomisd xmm0, xmm1
jp .L2
maxsd xmm0, xmm1
ret
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Add __issignaling inline based on the issignaling_inline implementation.
Improve the __issignalingf inline. Remove issignaling(f)_inline and its uses.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The //TRANSLIT and //IGNORE suffix supported by iconv_open
was not documented in the glibc manual. This commit adds the
documentation for the suffixes.
This fixes BZ #3794.
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
This patch disables multiarch memset variants when !IS_IN(libc),
because rtld can only use a single fixed implementation.
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch disables multiarch memcpy variants when !IS_IN(libc),
because rtld can only use a single fixed implementation.
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The test was not properly scheduled for execution with a Makefile
dependency.
Fixes commit 80cc58ea2d ("posix: Reset
wordexp_t fields with WRDE_REUSE (CVE-2025-15281 / BZ 33814").
The existing dlinfo request type RTLD_DI_ORIGIN used for querying the
value of the '$ORIGIN' dynamic string token is prone to buffer
overflows.
This commit adds a new request type named RTLD_DI_ORIGIN_PATH that
returns a pointer to the dynamic string token (i.e. the 'l_origin' field
in the link map) instead. The dlinfo manual is updated with the new
request type, and the description of RTLD_DI_ORIGIN is updated to
recommend RTLD_DI_ORIGIN_PATH instead.
A test for the new request type is also added to tst-dlinfo.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
When the result of ceill, floorl, roundl and truncl is zero, the sign of
the result must match the sign of the input. For the IBM 128-bit long
double format, the sign is determined by the high part.
Ensure the correct sign when the high part is the result of
computations, by copying the sign from the input high part to the output
high part. On POWER, this conveniently maps to the fcpsgn instruction.
In addition add test for the values provided in BZ #33623, and for the
opposite value when the result is 0.
Fixes: BZ #33623
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This prevents test failures because configuration file leftovers
unexpectedly change glibc for future tests. Whether this
triggers depends on test execution order.
Adding postclean.req files manually (before this change) appears
too error-prone.
Reviewed-by: DJ Delorie <dj@redhat.com>
#if defined ISO99 || defined ISO11 || defined ISO23 || defined XOPEN2K || defined POSIX2008 || defined XOPEN2K8
#if defined ISO99 || defined ISO11 || defined ISO23 || defined XOPEN2K || defined POSIX2008 || defined POSIX2024 || defined XOPEN2K8 || defined XOPEN2K24
#if defined ISO99 || defined ISO11 || defined ISO23 || defined XOPEN2K || defined XOPEN2K8 || defined POSIX2008
#if defined ISO99 || defined ISO11 || defined ISO23 || defined XOPEN2K || defined XOPEN2K8 || defined XOPEN2K24 || defined POSIX2008 || defined POSIX2024
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Florian Weimer
H.J. Lu
Jiri Stransky
Xiang Gao
Michael Ford
Adhemerval Zanella
Sachin Monga
Shengwen Cheng
Mike FABIAN
Pierre Blanchard
John David Anglin
Sergey Kolosov
Justus Winter
Carlos O'Donell
Wilco Dijkstra
Dylan Fleming
Yury Khrustalev
Samuel Thibault
Sana Kazi
Fabian Rast
Joseph Myers
Brian Jorgensen
Josef Johansson
Andreas Schwab
Sam James
Adam Yi
Alejandro Colomar
Diego Nieto Cid
Muhammad Kamran
Martin Coufal
Frédéric Bérat
Avinal Kumar
Pino Toscano
Stefan Liebler
Etienne Brateau
Matt Turner
Thomas Daubney
Rocket Ma
zombie12138
xiejiamei
Daan De Meyer
Paul Eggert
Weihong Ye
Shamil Abdulaev
Peter Collingbourne
Uros Bizjak
Jiho Lee
Petr Menšík
Collin Funk
Dmitry KovalenkoandFlorian Weimer
Siddhesh Poyarekar
Peter Bergner
WANG Rui
mengqinggang
Garccez
Michael Kelly
Charlotte Mcmenamin
DJ DelorieandFlorian Weimer
Lucas Chollet
Xi Ruoyao
Sajan Karumanchi
Dev Jain
Arjun Shankar
Deng Jianbo
Tomasz Kamiński
Yunze Zhu
Frédéric Bérat
Weixie Cui
Carlos Peón CostaandFlorian Weimer
Jonathan WakelyandTomasz Kamiński
Cosmina.Dunca@arm.com
Richard.Wild@arm.com
Nicolas Boulenguez
Michael Jeanson
Pádraig Brady
Jakub Jelinek
George Hu
Luca Boccassi
Andreas K. Hüttel
Aurelien Jarno