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>
Add the C23 memset_explicit function to glibc. Everything here is
closely based on the approach taken for explicit_bzero. This includes
the bits that relate to internal uses of explicit_bzero within glibc
(although we don't currently have any such internal uses of
memset_explicit), and also includes the nonnull attribute (when we
move to nonnull_if_nonzero for various functions following C2y, this
function should be included in that change).
The function is declared both for __USE_MISC and for __GLIBC_USE (ISOC23)
(so by default not just for compilers defaulting to C23 mode).
Tested for x86_64 and x86.
It now calls __libc_assert, which contains similar logic. The assert
call only requires memory allocation for the message translation, so
test-assert2.c is adapted to handle it.
It also removes the fxprintf from assert/assert_perror; although it
is not 100% backwards-compatible (write message only if there is a
file descriptor associated with the stderr). It now writes bytes
directly without going through the wide stream state.
Checked on aarch64-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Add check_mem_access(addr) function to check if memory at addr can
be written or read returning false if memory is not accessible.
This function changes signal handler for SIGSEGV and SIGBUS signals
when it is called first, and it is not thread-safe.
Co-authored-by: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To avoid linknamespace issues on old standards. It is required
if the fallback fma implementation is used if/when it is also
used internally for other implementation.
Reviewed-by: DJ Delorie <dj@redhat.com>
To avoid linknamespace issues on old standards. It is required
if the fallback fma implementation is used if/when it is also
used internally for other implementation.
Reviewed-by: DJ Delorie <dj@redhat.com>
Remove all unused atomics. Replace uses of catomic_increment and
catomic_decrement with atomic_fetch_add_relaxed which maps to a standard
compiler builtin. Relaxed memory ordering is correct for simple counters
since they only need atomicity.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Switch to standard builtin atomics by removing the defines for
!USE_ATOMIC_COMPILER_BUILTINS.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Use builtin atomics for atomic_compare_and_exchange_* and
atomic_exchange_and_add if USE_ATOMIC_COMPILER_BUILTINS is enabled.
This allows removing target atomic-machine.h headers.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch replaces _dl_stack_flags global variable by
_dl_stack_prot_flags.
The advantage is that any convertion from p_flags to final used mprotect
flags occurs at loading of p_flags. It avoids repeated spurious
convertions of _dl_stack_flags, for example in allocate_thread_stack.
This modification was suggested in:
https://sourceware.org/pipermail/libc-alpha/2025-March/165537.html
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Since clang 20 defines __INT64_C and __UINT64_C as built-in macros, undef
them for glibc build and test. This fixes BZ #33311.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
The changes in commit a93d9e03a3
("Extend struct r_debug to support multiple namespaces [BZ #15971]")
break the dyninst dynamic instrumentation tool. It brings its
own definition of _r_debug (rather than a declaration).
Furthermore, it turns out it is rather hard to use the proposed
handshake for accessing _r_debug via DT_DEBUG. If applications want
to access _r_debug, they can do so directly if the relevant code has
been built as PIC. To protect against harm from accidental copy
relocations due to linker relaxations, this commit restores copy
relocation support by adjusting both copies if interposition or
copy relocations are in play. Therefore, it is possible to
use a hidden reference in ld.so to access _r_debug.
Only perform the copy relocation initialization if libc has been
loaded. Otherwise, the ld.so search scope can be empty, and the
lookup of the _r_debug symbol mail fail.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Add DL_ADDRESS_WITHOUT_RELOC to force an address into a general purpose
register to prevent loading it into a vector register directly before
run-time relocation. This is an updated fix for BZ #33088.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The iovec size should account for all substrings between each conversion
specification. For the format:
"abc %s efg"
The list of substrings are:
["abc ", arg, " efg]
which is 2 times the number of maximum arguments *plus* one.
This issue triggered 'out of bounds' errors by stdlib/tst-bz20544 when
glibc is built with experimental UBSAN support [1].
Besides adjusting the iovec size, a new runtime and check is added to
avoid wrong __libc_message_impl usage.
Checked on x86_64-linux-gnu.
[1] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/ubsan-undef
Co-authored-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Add simple-to-use iterator macros for arrays. They are used instead
of explicit for statements, like:
/* Test all common speeds */
array_foreach_const (ts, test_speeds)
test (fd, *ts);
In this case, ts will be a const pointer to each of the elements of
test_speeds in turn.
Named array_foreach*() to allow for other kinds of equivalent iterator
macros in the future.
Signed-off-by: "H. Peter Anvin" (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Add an explicitly numeric interface for baudrate setting. For glibc,
this only announces what is a fair accompli, but this is a plausible
way forward for standardization, and may be possible to infill on
non-compliant systems. The POSIX committee has stated:
[https://www.austingroupbugs.net/view.php?id=1916#c7135]
A future version of this standard is expected to add at least
the following symbolic constants for use as values of objects
of type speed_t: B57600, B115200, B230400, B460800, and
B921600.
Implementations are encouraged to propose additional
interfaces which will make it possible to set and query a
wider range of speeds than just those enumerated by the
constants beginning with B. If a set of common interfaces
emerges between several implementations, a future version of
this standard will likely add those interfaces.
This is exactly that interface.
The use of the term "baud" is due to the need to have a term
contrasting "speed", and it is already well established as a legacy
term -- including in the names of the legacy Bxxx
constants. Futhermore, it *is* valid from the point of view that the
termios interface fundamentally emulates an RS-232 serial port as far
as the application software is concerned.
The documentation states that for the current version of glibc,
speed_t == baud_t, but explicitly declares that this may not be the
case in the future.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Replace local_isatty() inlined in libio with a proper function
__isatty_nostatus(). This allows simpler system-specific
implementations that don't need to touch errno at all.
Note: I left the prototype in include/unistd.h (the internal header
file.) It didn't much make sense to me to put it in a different header
(not-cancel.h), but perhaps someone can elucidate the need.
Add such an implementation for Linux, with a generic fallback.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
There is a prototype for an internal __tcsetattr() function in
include/termios.h, but tcsetattr without __ were still declared as the
actual functions.
Make this match the comment and make __tcsetattr() an internal
interface. This will be required to version struct termios for Linux on
MIPS and SPARC.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Paul Eggert
Wilco Dijkstra
Adhemerval Zanella
Yury Khrustalev
Joseph Myers
Samuel Thibault
Collin Funk
Prasanna Paithankar
Cupertino Miranda
H.J. Lu
Andreas K. Hüttel
Florian Weimer
H. Peter Anvin
Jonathan Wakely