Since af34b1376a ("elf: Initialize static TLS before relocation
processing", BZ 34164) dropped the 'defer-if-not-relocated' branch in
_dl_try_allocate_static_tls, nothing sets l_need_tls_init any more. The
second pass in update_tls_slotinfo, guarded by l_need_tls_init, is
therefore dead: its _dl_update_slotinfo / _dl_init_static_tls calls never
run, and the static TLS image is initialised inline during relocation (IE
model) or lazily on first dynamic-TLS access instead.
Remove the dead loop, the now write-only l_need_tls_init field and its
clear in _dl_allocate_tls_init. No functional change.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
I also run the elf tests on armv7-a, alpha, loongarch64, mips64le,
powerpc, riscv, and s390x using qemu system.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
.. and openat64.
Linux 7.2 (31cf44efa6df72a524b40adefb80539f3a4e13ba) allows openat, openat2
to take a NULL path with the new O_EMPTYPATH flag, so the nonnull attribute
is no longer sound. Drop it.
Bug: https://sourceware.org/PR34313
Reviewed-by: Paul Eggert <eggert@cs.ucla.edu>
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>
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>
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>
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 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>
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.
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>
Reinstate HAVE_64B_ATOMICS configure check that was reverted by commit
7fec8a5de6 due to BZ #33632. This was
fixed by 3dd2cbfa35 by only allowing
64-bit atomics on sem_t if its type is 8-byte aligned. Rebase and add
in cleanups in include/atomic.h that were omitted.
Fix an issue with sparcv8-linux-gnu-leon3 forcing -mcpu=v8 for rtld.c which
overrules -mcpu=leon3 and causes __atomic_always_lock_free (4, 0) to
incorrectly return 0 and trigger asserts in atomics. Remove this as it
seems to be a workaround for an issue in 1997.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Clang issues a warning for double alias redirection, indicating that thei
original symbol is used even if a weak definition attempts to override it.
For instance, in the construction:
int __internal_impl (...) {}
weak_alias (__internal_impl, external_impl);
#if SOMETHING
weak_alias (external_impl, another_external_impl)
#endif
Clang warns that another_external_impl always resolves to __internal_impl,
even if external_impl is a weak reference. Using the internal symbol for
both aliases resolves this warning.
This issue also occurs with certain libc_hidden_def usage:
int __internal_impl (...) {}
weak_alias (__internal_impl, __internal_alias)
libc_hidden_weak (__internal_alias)
In this case, using a strong_alias is sufficient to avoid the warning
(since the alias is internal, there is no need to use a weak alias).
However, for the constructions like:
int __internal_impl (...) {}
weak_alias (__internal_impl, __internal_alias)
libc_hidden_def (__internal_alias)
weak_alias (__internal_impl, external_alias)
libc_hidden_def (external_alias)
Clang warns that the internal external_alias will always resolve to
__GI___internal_impl, even if a weak definition of __GI_internal_impl is
overridden. For this case, a new macro named static_weak_alias is used
to create a strong alias for SHARED, or a weak_alias otherwise.
With these changes, there is no need to check and enable the
-Wno-ignored-attributes suppression when using clang.
Checked with a build on affected ABIs, and a full check on aarch64,
armhf, i686, and x86_64.
Reviewed-by: Sam James <sam@gentoo.org>
The TIME_MONOTONIC maps to POSIX's CLOCK_MONOTONIC, TIME_ACTIVE to
CLOCK_PROCESS_CPUTIME_ID, and TIME_THREAD_ACTIVE to
CLOCK_THREAD_CPUTIME_ID.
No Linux specific timer are added as extension.
Co-authored-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Paul Eggert <eggert@cs.ucla.edu>
C23 defines library macros __STDC_VERSION_<header>_H__ to indicate
that a header has support for new / changed features from C23. Now
that all the required library features are implemented in glibc,
define these macros. I'm not sure this is sufficiently much of a
user-visible feature to be worth a mention in NEWS.
Tested for x86_64.
There are various optional C23 features we don't yet have, of which I
might look at the Annex H ones (floating-point encoding conversion
functions and _Float16 functions) next.
* Optional time bases TIME_MONOTONIC, TIME_ACTIVE, TIME_THREAD_ACTIVE.
See
<https://sourceware.org/pipermail/libc-alpha/2023-June/149264.html>
- we need to review / update that patch. (I think patch 2/2,
inventing new names for all the nonstandard CLOCK_* supported by the
Linux kernel, is rather more dubious.)
* Updating conform/ tests for C23.
* Defining the rounding mode macro FE_TONEARESTFROMZERO for RISC-V (as
far as I know, the only architecture supported by glibc that has
hardware support for this rounding mode for binary floating point)
and supporting it throughout glibc and its tests (especially the
string/numeric conversions in both directions that explicitly handle
each possible rounding mode, and various tests that do likewise).
* Annex H floating-point encoding conversion functions. (It's not
entirely clear which are optional even given support for Annex H;
there's some wording applied inconsistently about only being
required when non-arithmetic interchange formats are supported; see
the comments I raised on the WG14 reflector on 23 Oct 2025.)
* _Float16 functions (and other header and testcase support for this
type).
* Decimal floating-point support.
* Fully supporting __int128 and unsigned __int128 as integer types
wider than intmax_t, as permitted by C23. Would need doing in
coordination with GCC, see GCC bug 113887 for more discussion of
what's involved.
clang generates internal calls for some _chk symbol, so add internal
aliases for them, and stub some with rtld-stubbed-symbols to avoid
ld.so linker issues.
Reviewed-by: Sam James <sam@gentoo.org>
Work around the clang limitation wrt inline function and attribute
definition, where it does not allow to 'add' new attribute if a
function is already defined:
clang on x86_64 fails to build s_fabsf128.c with:
../sysdeps/ieee754/float128/../ldbl-128/s_fabsl.c:32:1: error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
32 | libm_alias_ldouble (__fabs, fabs)
| ^
../sysdeps/generic/libm-alias-ldouble.h:63:38: note: expanded from macro 'libm_alias_ldouble'
63 | #define libm_alias_ldouble(from, to) libm_alias_ldouble_r (from, to, )
| ^
../sysdeps/ieee754/float128/float128_private.h:133:43: note: expanded from macro 'libm_alias_ldouble_r'
133 | #define libm_alias_ldouble_r(from, to, r) libm_alias_float128_r (from, to, r)
| ^
../sysdeps/ieee754/float128/s_fabsf128.c:5:3: note: expanded from macro 'libm_alias_float128_r'
5 | static_weak_alias (from ## f128 ## r, to ## f128 ## r); \
| ^
./../include/libc-symbols.h:166:46: note: expanded from macro 'static_weak_alias'
166 | # define static_weak_alias(name, aliasname) weak_alias (name, aliasname)
| ^
./../include/libc-symbols.h:154:38: note: expanded from macro 'weak_alias'
154 | # define weak_alias(name, aliasname) _weak_alias (name, aliasname)
| ^
./../include/libc-symbols.h:156:52: note: expanded from macro '_weak_alias'
156 | extern __typeof (name) aliasname __attribute__ ((weak, alias (#name))) \
| ^
../include/math.h:134:1: note: previous definition is here
134 | fabsf128 (_Float128 x)
If compiler does not support __USE_EXTERN_INLINES we need to route
fabsf128 call to an internal symbol.
When we want to inline builtin math functions, like truncf, for
extern float truncf (float __x) __attribute__ ((__nothrow__ )) __attribute__ ((__const__));
extern float __truncf (float __x) __attribute__ ((__nothrow__ )) __attribute__ ((__const__));
float (truncf) (float) asm ("__truncf");
compiler may redirect truncf calls to __truncf, instead of inlining it
(for instance, clang). The USE_TRUNCF_BUILTIN is 1 to indicate that
truncf should be inlined. In this case, we don't want the truncf
redirection:
1. For each math function which may be inlined, we define
#if USE_TRUNCF_BUILTIN
# define NO_truncf_BUILTIN inline_truncf
#else
# define NO_truncf_BUILTIN truncf
#endif
in <math-use-builtins.h>.
2. Include <math-use-builtins.h> in include/math.h.
3. Change MATH_REDIRECT to
#define MATH_REDIRECT(FUNC, PREFIX, ARGS) \
float (NO_ ## FUNC ## f ## _BUILTIN) (ARGS (float)) \
asm (PREFIX #FUNC "f");
With this change If USE_TRUNCF_BUILTIN is 0, we get
float (truncf) (float) asm ("__truncf");
truncf will be redirected to __truncf.
And for USE_TRUNCF_BUILTIN 1, we get:
float (inline_truncf) (float) asm ("__truncf");
In both cases either truncf will be inlined or the internal alias
(__truncf) will be called.
It is not required for all math-use-builtin symbol, only the one
defined in math.h. It also allows to remove all the math-use-builtin
inclusion, since it is now implicitly included by math.h.
For MIPS, some math-use-builtin headers include sysdep.h and this
in turn includes a lot of extra headers that do not allow ldbl-128
code to override alias definition (math.h will include
some stdlib.h definition). The math-use-builtin only requires
the __mips_isa_rev, so move the defintion to sgidefs.h.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The 53807741fb added a configure check
for 64-bit atomic operations that were not previously enabled on some
32-bit ABIs.
However, the NPTL semaphore code casts a sem_t to a new_sem and issues
a 64-bit atomic operation for __HAVE_64B_ATOMICS. Since sem_t has
32-bit alignment on 32-bit architectures, this prevents the use of
64-bit atomics even if the ABI supports them.
Assume 64-bit atomic support from __WORDSIZE, which maps to how glibc
defines it before the broken change. Also rename __HAVE_64B_ATOMICS
to USE_64B_ATOMICS to define better the flag meaning.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Some symbols that might be auto-generated by the compiler are redefined
to internal alias (for instance mempcpy to __mempcpy). However, if fortify
is enabled, the fortify wrapper is define before the alias re-defined and
clang warns attribute declaration must precede definition.
Use an asm alias if compiler does not support it, instead of an
attribute.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* include/features.h (_POSIX_C_SOURCE): Document the value of 202405L
for POSIX.1-2024. Set it to 202405L when _GNU_SOURCE or _DEFAULT_SOURCE
is defined.
(_XOPEN_SOURCE): Document the value of 800 for POSIX-1.2024. Set it to
800 when _GNU_SOURCE is defined.
(__USE_XOPEN2K24, __USE_XOPEN2K24XSI): New internal macros. Set them
when _POSIX_C_SOURCE is 202405L or greater and/or when _XOPEN_SOURCE is
800 or greater.
* manual/creature.texi (Feature Test Macros): Document the new values
for _POSIX_C_SOURCE and _XOPEN_SOURCE.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Collin Funk <collin.funk1@gmail.com>
i386 and m68k architectures should use math-use-builtins-sqrt.h rather
than relying on architecture-specific or inline assembly implementations.
The PowerPC optimization for PPC 601/603 (30 years old) is removed.
Tested on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
The only usage was for pthread_spin_lock, introduced by 12d2dd7060,
as a way to optimize the code for certain architectures. Now that atomic
builtins are used by default, let the compiler use the best code sequence
for the atomic exchange.
Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
All ABIs, except alpha and sparc, define it to
atomic_full_barrier/__sync_synchronize, which can be mapped to
__atomic_thread_fence (__ATOMIC_RELEASE).
For alpha, it uses a 'wmb' which does not map to any of C11
barriers.
For sparc it uses a stronger 'member #LoadStore | #StoreStore',
where the release barrier maps to just 'membar #StoreLoad'. The
patch keeps the sparc definition.
For PowerPC, it allows the use of lwsync for additional chips
(since _ARCH_PWR4 does not cover all chips that support it).
Tested on aarch64-linux-gnu.
Co-authored-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
All ABIs, except alpha, powerpc, and x86_64, define it to
atomic_full_barrier/__sync_synchronize, which can be mapped to
__atomic_thread_fence (__ATOMIC_SEQ_CST) in most cases, with the
exception of aarch64 (where the acquire fence is generated as
'dmb ishld' instead of 'dmb ish').
For s390x, it defaults to a memory barrier where __sync_synchronize
emits a 'bcr 15,0' (which the manual describes as pipeline
synchronization).
For PowerPC, it allows the use of lwsync for additional chips
(since _ARCH_PWR4 does not cover all chips that support it).
Tested on aarch64-linux-gnu, where the acquire produces a different
instruction that the current code.
Co-authored-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
All ABIs save for sparcv9 and s390 defines it to __sync_synchronize,
which can be mapped to __atomic_thread_fence (__ATOMIC_SEQ_CST).
For Sparc, it uses a stricter #StoreStore|#LoadStore|#StoreLoad|#LoadLoad
instead of the #StoreLoad generated by __sync_synchronize.
For s390x, it defaults to a memory barrier where __sync_synchronize
emits a 'bcr 15,0' (which the manual describes as pipeline synchronization).
The barrier is used only in one place (pthread_mutex_setprioceiling),
and using a stricter barrier for s390 is ok performance-wise.
Co-authored-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
When building with -Og to enable debugging, there is currently a compiler error
because if __libc_message_wrapper() is not inline, the __va_arg_pack_len macro
cannot be used.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The internal header redefines the some internal argp functions with
attribute_hidden, which triggers clang warning of mismatched attributes.
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
The __ifunc_resolver macro expands to:
extern __typeof (__redirect_name) name __attribute__ ((ifunc ("iname_ifunc")));
static __typeof (__redirect_name) *name_ifunc (void) { [...] };
And although NAME_IFUNC is and alias for NAME, clang still emits
an 'unused function 'name_ifunc' [-Werror,-Wunused-function]'
warning. The static is used to avoid name pollution on static
linkage.
Reviewed-by: Sam James <sam@gentoo.org>
clang does not allow to redefine attributes after function declaration.
Although it work for external usage, its breaks the build for internal
symbol that glibc provides as optimization (for instance bsearch
with stdlib-bsearch.h or __cmsg_nxthdr).
Disable such optimization for clang while building glibc.
Reviewed-by: Sam James <sam@gentoo.org>
Remove the odd atomic_forced_read which is neither atomic nor forced.
Some uses are completely redundant, so simply remove them. In other cases
the intended use is to force a memory ordering, so use acquire load for those.
In yet other cases their purpose is unclear, for example __nscd_cache_search
appears to allow concurrent accesses to the cache while it is being garbage
collected by another thread! Use relaxed atomic loads here to block spills
from accidentally reloading memory that is being changed.
Passes regress on AArch64, OK for commit?
The struct shmdir_name in include/shm-directory.h has name field to
contains the full path of the POSIX IPC object (shm and sem).
The size was previously set to sizeof (SHMDIR) + 4 + NAME_MAX, where 4
bytes were reserved for the optional "sem." prefix.
This led to incorrect execution of the __shm_get_name function
in posix/shm-directory.c which is used accross in shm_[open/unlink] and
sem_[open/unlink] functions.
For shm_[open/unlink]:
This is because the name field was large enough to hold 268 characters
(255 + 4 + 9) instead of the maximum allowed 263 characters (255 + 9).
This caused the __shm_get_name to not throw ENAMETOOLONG error when the
name length exceeded NAME_MAX (255) upto 259 characters.
For sem_[open/unlink]:
Similarly, the __shm_get_name incorrectly returned success for names of
length 255 instead of 251 (255 - 4).
This was overlooked as finally these functions throw the correct
ENAMETOOLONG error; which was thrown by the openat syscall, which is
called later in the shm_* and sem_* functions.
This patch corrects the size of name field in struct shmdir_name to
sizeof (SHMDIR) + NAME_MAX. The __shm_get_name function return
ENAMETOOLONG if alloc_buffer_has_failed returns true (which only happens
when copy length > alloc_buffer_size (buffer)).
Relevant runtime monitoring were done in gdb to confirm the same.
Signed-off-by: Prasanna Paithankar <paithankarprasanna@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Adhemerval Zanella
Sam James
Andreas K. Hüttel
Florian Weimer
Uros Bizjak
Samuel Thibault
Paul Eggert
Wilco DijkstraandAdhemerval Zanella
Yury Khrustalev
Joseph Myers
Collin Funk
Prasanna Paithankar