Jiamei Xie [Tue, 14 Oct 2025 12:14:11 +0000 (20:14 +0800)]
x86: fix wmemset ifunc stray '!' (bug 33542)
The ifunc selector for wmemset had a stray '!' in the
X86_ISA_CPU_FEATURES_ARCH_P(...) check:
if (X86_ISA_CPU_FEATURE_USABLE_P (cpu_features, AVX2)
&& X86_ISA_CPU_FEATURES_ARCH_P (cpu_features,
AVX_Fast_Unaligned_Load, !))
This effectively negated the predicate and caused the AVX2/AVX512
paths to be skipped, making the dispatcher fall back to the SSE2
implementation even on CPUs where AVX2/AVX512 are available. The
regression leads to noticeable throughput loss for wmemset.
Remove the stray '!' so the AVX_Fast_Unaligned_Load capability is
tested as intended and the correct AVX2/EVEX variants are selected.
Impact:
- On AVX2/AVX512-capable x86_64, wmemset no longer incorrectly
falls back to SSE2; perf now shows __wmemset_evex/avx2 variants.
Testing:
- benchtests/bench-wmemset shows improved bandwidth across sizes.
- perf confirm the selected symbol is no longer SSE2.
Signed-off-by: xiejiamei <xiejiamei@hygon.com> Signed-off-by: Li jing <lijing@hygon.cn> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
(cherry picked from commit 4d86b6cdd8132e0410347e07262239750f86dfb4)
This commit adds tests for the following use cases relevant to handing of
the SME state:
- fork() and vfork()
- clone() and clone3()
- signal handler
While most cases are trivial, the case of clone3() is more complicated since
the clone3() symbol is not public in Glibc.
To avoid having to check all possible ways clone3() may be called via other
public functions (e.g. vfork() or pthread_create()), we put together a test
that links directly with clone3.o. All the existing functions that have calls
to clone3() may not actually use it, in which case the outcome of such tests
would be unexpected. Having a direct call to the clone3() symbol in the test
allows to check precisely what we need to test: that the __arm_za_disable()
function is indeed called and has the desired effect.
Linking to clone3.o also requires linking to __arm_za_disable.o that in
turn requires the _dl_hwcap2 hidden symbol which to provide in the test
and initialise it before using.
aarch64: clear ZA state of SME before clone and clone3 syscalls
This change adds a call to the __arm_za_disable() function immediately
before the SVC instruction inside clone() and clone3() wrappers. It also
adds a macro for inline clone() used in fork() and adds the same call to
the vfork implementation. This sets the ZA state of SME to "off" on return
from these functions (for both the child and the parent).
The __arm_za_disable() function is described in [1] (8.1.3). Note that
the internal Glibc name for this function is __libc_arm_za_disable().
When this change was originally proposed [2,3], it generated a long
discussion where several questions and concerns were raised. Here we
will address these concerns and explain why this change is useful and,
in fact, necessary.
In a nutshell, a C library that conforms to the AAPCS64 spec [1] (pertinent
to this change, mainly, the chapters 6.2 and 6.6), should have a call to the
__arm_za_disable() function in clone() and clone3() wrappers. The following
explains in detail why this is the case.
When we consider using the __arm_za_disable() function inside the clone()
and clone3() libc wrappers, we talk about the C library subroutines clone()
and clone3() rather than the syscalls with similar names. In the current
version of Glibc, clone() is public and clone3() is private, but it being
private is not pertinent to this discussion.
We will begin with stating that this change is NOT a bug fix for something
in the kernel. The requirement to call __arm_za_disable() does NOT come from
the kernel. It also is NOT needed to satisfy a contract between the kernel
and userspace. This is why it is not for the kernel documentation to describe
this requirement. This requirement is instead needed to satisfy a pure userspace
scheme outlined in [1] and to make sure that software that uses Glibc (or any
other C library that has correct handling of SME states (see below)) conforms
to [1] without having to unnecessarily become SME-aware thus losing portability.
To recap (see [1] (6.2)), SME extension defines SME state which is part of
processor state. Part of this SME state is ZA state that is necessary to
manage ZA storage register in the context of the ZA lazy saving scheme [1]
(6.6). This scheme exists because it would be challenging to handle ZA
storage of SME in either callee-saved or caller-saved manner.
There are 3 kinds of ZA state that are defined in terms of the PSTATE.ZA
bit and the TPIDR2_EL0 register (see [1] (6.6.3)):
As [1] (6.7.2) outlines, every subroutine has exactly one SME-interface
depending on the permitted ZA-states on entry and on normal return from
a call to this subroutine. Callers of a subroutine must know and respect
the ZA-interface of the subroutines they are using. Using a subroutine
in a way that is not permitted by its ZA-interface is undefined behaviour.
In particular, clone() and clone3() (the C library functions) have the
ZA-private interface. This means that the permitted ZA-states on entry
are "off" and "dormant" and that the permitted states on return are "off"
or "dormant" (but if and only if it was "dormant" on entry).
This means that both functions in question should correctly handle both
"off" and "dormant" ZA-states on entry. The conforming states on return
are "off" and "dormant" (if inbound state was already "dormant").
This change ensures that the ZA-state on return is always "off". Note,
that, in the context of clone() and clone3(), "on return" means a point
when execution resumes at certain address after transferring from clone()
or clone3(). For the caller (we may refer to it as "parent") this is the
return address in the link register where the RET instruction jumps. For
the "child", this is the target branch address.
So, the "off" state on return is permitted and conformant. Why can't we
retain the "dormant" state? In theory, we can, but we shouldn't, here is
why.
Every subroutine with a private-ZA interface, including clone() and clone3(),
must comply with the lazy saving scheme [1] (6.7.2). This puts additional
responsibility on a subroutine if ZA-state on return is "dormant" because
this state has special meaning. The "caller" (that is the place in code
where execution is transferred to, so this include both "parent" and "child")
may check the ZA-state and use it as per the spec of the "dormant" state that
is outlined in [1] (6.6.6 and 6.6.7).
Conforming to this would require more code inside of clone() and clone3()
which hardly is desirable.
For the return to "parent" this could be achieved in theory, but given that
neither clone() nor clone3() are supposed to be used in the middle of an
SME operation, if wouldn't be useful. For the "return" to "child" this
would be particularly difficult to achieve given the complexity of these
functions and their interfaces. Most importantly, it would be illegal
and somewhat meaningless to allow a "child" to start execution in the
"dormant" ZA-state because the very essence of the "dormant" state implies
that there is a place to return and that there is some outer context that
we are allowed to interact with.
To sum up, calling __arm_za_disable() to ensure the "off" ZA-state when the
execution resumes after a call to clone() or clone3() is correct and also
the most simple way to conform to [1].
Can there be situations when we can avoid calling __arm_za_disable()?
Calling __arm_za_disable() implies certain (sufficiently small) overhead,
so one might rightly ponder avoiding making a call to this function when
we can afford not to. The most trivial cases like this (e.g. when the
calling thread doesn't have access to SME or to the TPIDR2_EL0 register)
are already handled by this function (see [1] (8.1.3 and 8.1.2)). Reasoning
about other possible use cases would require making code inside clone() and
clone3() more complicated and it would defeat the point of trying to make
an optimisation of not calling __arm_za_disable().
Why can't the kernel do this instead?
The handling of SME state by the kernel is described in [4]. In short,
kernel must not impose a specific ZA-interface onto a userspace function.
Interaction with the kernel happens (among other thing) via system calls.
In Glibc many of the system calls (notably, including SYS_clone and
SYS_clone3) are used via wrappers, and the kernel has no control of them
and, moreover, it cannot dictate how these wrappers should behave because
it is simply outside of the kernel's remit.
However, in certain cases, the kernel may ensure that a "child" doesn't
start in an incorrect state. This is what is done by the recent change
included in 6.16 kernel [5]. This is not enough to ensure that code that
uses clone() and clone3() function conforms to [1] when it runs on a
system that provides SME, hence this change.
nptl: Fix MADV_GUARD_INSTALL logic for thread without guard page (BZ 33356)
The main issue is that setup_stack_prot fails to account for cases where
the cached thread stack lacks a guard page, which can cause madvise to
fail. Update the logic to also handle whether MADV_GUARD_INSTALL is
supported when resizing the guard page.
Checked on x86_64-linux-gnu with 6.8.0 and 6.15 kernels.
nss: Group merge does not react to ERANGE during merge (bug 33361)
The break statement in CHECK_MERGE is expected to exit the surrounding
while loop, not the do-while loop with in the macro. Remove the
do-while loop from the macro. It is not needed to turn the macro
expansion into a single statement due to the way CHECK_MERGE is used
(and the statement expression would cover this anyway).
libio: Define AT_RENAME_* with the same tokens as Linux
Linux uses different expressions for the RENAME_* and AT_RENAME_*
constants. Mirror that in <stdio.h>, so that the macro redefinitions
do not result in preprocessor warnings.
Pierre Blanchard [Wed, 20 Aug 2025 17:41:50 +0000 (17:41 +0000)]
AArch64: Fix SVE powf routine [BZ #33299]
Fix a bug in predicate logic introduced in last change.
A slight performance improvement from relying on all true
predicates during conversion from single to double.
This fixes BZ #33299.
affects both i386 and x86-64, also add GLIBC_ABI_GNU2_TLS version to i386
to indicate the working GNU2 TLS run-time. For x86-64, the additional
GNU2 TLS run-time bug fix is needed for
H.J. Lu [Thu, 14 Aug 2025 14:03:20 +0000 (07:03 -0700)]
x86-64: Add GLIBC_ABI_DT_X86_64_PLT [BZ #33212]
When the linker -z mark-plt option is used to add DT_X86_64_PLT,
DT_X86_64_PLTSZ and DT_X86_64_PLTENT, the r_addend field of the
R_X86_64_JUMP_SLOT relocation stores the offset of the indirect
branch instruction. However, glibc versions without the commit:
x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT
According to x86-64 psABI, r_addend should be ignored for R_X86_64_GLOB_DAT
and R_X86_64_JUMP_SLOT. Since linkers always set their r_addends to 0, we
can ignore their r_addends.
Reviewed-by: Fangrui Song <maskray@google.com>
won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation.
Such programs and shared libraries will fail at run-time randomly.
Add GLIBC_ABI_DT_X86_64_PLT version to indicate that glibc is compatible
with DT_X86_64_PLT.
The linker can add the glibc GLIBC_ABI_DT_X86_64_PLT version dependency
whenever -z mark-plt is passed to the linker. The resulting programs and
shared libraries will fail to load at run-time against libc.so without the
GLIBC_ABI_DT_X86_64_PLT version, instead of fail randomly.
Add GLIBC_ABI_GNU2_TLS version to indicate that glibc has the working
GNU2 TLS run-time. Linker can add the GLIBC_ABI_GNU2_TLS version to
binaries which depend on the working GNU2 TLS run-time:
so that such programs and shared libraries will fail to load and run at
run-time against libc.so without the GLIBC_ABI_GNU2_TLS version, instead
of fail silently at random.
Add GLIBC_ABI_GNU_TLS version to indicate that glibc has the working
GNU TLS run-time. Linker can add the GLIBC_ABI_GNU_TLS version to
binaries which depend on the working TLS run-time so that such programs
and shared libraries will fail to load and run at run-time against
libc.so without the GLIBC_ABI_GNU_TLS version, instead of fail silently
at random.
Use TLS initial-exec model for __libc_tsd_CTYPE_* thread variables [BZ #33234]
Commit 10a66a8e421b ("Remove <libc-tsd.h>") removed the TLS initial-exec
(IE) model attribute from the __libc_tsd_CTYPE_* thread variable declarations
and definitions. Commit a894f04d8776 ("Optimize __libc_tsd_* thread
variable access") restored it on declarations.
Restore the TLS initial-exec model attribute on __libc_tsd_CTYPE_* thread
variable definitions.
This resolves test tst-locale1 failure on s390 32-bit, when using a
GNU linker without the fix from GNU binutils commit aefebe82dc89
("IBM zSystems: Fix offset relative to static TLS").
Samuel Thibault [Tue, 29 Jul 2025 23:55:22 +0000 (01:55 +0200)]
malloc: Make sure tcache_key is odd enough
We want tcache_key not to be a commonly-occurring value in memory, so ensure
a minimum amount of one and zero bits.
And we need it non-zero, otherwise even if tcache_double_free_verify sets
e->key to 0 before calling __libc_free, it gets called again by __libc_free,
thus looping indefinitely.
MAX_TCACHE_SMALL_SIZE should use chunk size since it is used after
checked_request2size. Increase limit of tcache_max_bytes by 1 since all
comparisons use '<'. As a result, the last tcache entry is now used as
expected.
H.J. Lu [Sat, 19 Jul 2025 14:43:28 +0000 (07:43 -0700)]
tst-freopen4-main.c: Call support_capture_subprocess with chroot
Update tst-freopen4-main.c to call support_capture_subprocess with chroot,
which makes temporary files inaccessible, so that temporary files can be
deleted.
This partially fixes BZ #33182.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
(cherry picked from commit 6463d4a7b28e5ee3891c34a8a1f0a59c24dfa9de)
H.J. Lu [Sat, 19 Jul 2025 14:43:27 +0000 (07:43 -0700)]
tst-fopen-threaded.c: Delete temporary file
Update tst-fopen-threaded.c to call support_create_temp_directory to
create a temporary directory and open "file" in the temporary directory,
instead of using /tmp/openclosetest and leaving it behind.
This partially fixes BZ #33182.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
(cherry picked from commit e7db5150603bb2224a2bfd9628cae04ddcbe49e3)
nptl: Fix SYSCALL_CANCEL for return values larger than INT_MAX (BZ 33245)
The SYSCALL_CANCEL calls __syscall_cancel, which in turn
calls __internal_syscall_cancel with an 'int' return instead of the
expected 'long int'. This causes issues with syscalls that return
values larger than INT_MAX, such as copy_file_range [1].
Florian Weimer [Fri, 1 Aug 2025 17:27:35 +0000 (19:27 +0200)]
elf: Handle ld.so with LOAD segment gaps in _dl_find_object (bug 31943)
Detect if ld.so not contiguous and handle that case in _dl_find_object.
Set l_find_object_processed even for initially loaded link maps,
otherwise dlopen of an initially loaded object adds it to
_dlfo_loaded_mappings (where maps are expected to be contiguous),
in addition to _dlfo_nodelete_mappings.
Test elf/tst-link-map-contiguous-ldso iterates over the loader
image, reading every word to make sure memory is actually mapped.
It only does that if the l_contiguous flag is set for the link map.
Otherwise, it finds gaps with mmap and checks that _dl_find_object
does not return the ld.so mapping for them.
The test elf/tst-link-map-contiguous-main does the same thing for
the libc.so shared object. This only works if the kernel loaded
the main program because the glibc dynamic loader may fill
the gaps with PROT_NONE mappings in some cases, making it contiguous,
but accesses to individual words may still fault.
Test elf/tst-link-map-contiguous-libc is again slightly different
because the dynamic loader always fills the gaps with PROT_NONE
mappings, so a different form of probing has to be used.
stdlib: resolve a double lock init issue after fork [BZ #32994]
The __abort_fork_reset_child (introduced in d40ac01cbbc66e6d9dbd8e3485605c63b2178251) call resets the lock after the
fork. This causes a DRD regression in valgrind
(https://bugs.kde.org/show_bug.cgi?id=503668), as it's effectively a
double initialization, despite it being actually ok in this case. As
suggested in https://sourceware.org/bugzilla/show_bug.cgi?id=32994#c2
we replace it here with a memcpy of another initialized lock instead,
which makes valgrind happy.
sframe: Add support for SFRAME_F_FDE_FUNC_START_PCREL flag
The Sframe V2 has a new errata which introduces the
SFRAME_F_FDE_FUNC_START_PCREL flag. This flag indicates the encoding
of the SFrame FDE function start address field like this:
- if set, sfde_func_start_address field contains the offset in bytes
to the start PC of the associated function from the field itself.
- if unset, sfde_func_start_address field contains the offset in bytes
to the start PC of the associated function from the start of the
SFrame section.
Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com> Reviewed-by: Sam James <sam@gentoo.org>
And add extra checks to enable for binutils 2.45 and if the architecture
explicitly enables it. When SFrame is disabled, all the related code
is also not enabled for backtrace() and _dl_find_object(), so SFrame
backtracking is not used even if the binary has the SFrame segment.
This patch also adds some other related fixes:
* Fixed an issue with AC_CHECK_PROG_VER, where the READELF_SFRAME
usage prevented specifying a different readelf through READELF
environment variable at configure time.
* Add an extra arch-specific internal definition,
libc_cv_support_sframe, to disable --enable-sframe on architectures
that have binutils but not glibc support (s390x).
* Renamed the tests without the .sframe segment and move the
tst-backtrace1 from pthread to debug.
* Use the built compiler strip to remove the .sframe segment,
instead of the system one (which might not support SFrame).
Checked on x86_64-linux-gnu and aarch64-linux-gnu.
manual: Use @Theglibc{} at sentence start in terminal documentation
Fixes commit 5dd2a19ad5218261cee064 ("termios: manual: improve the
explanation of various tty concepts") and commit c744519bad8106769760
("termios: manual: document the SPEED_MAX and BAUD_MAX constants").
debug: Link tst-sprintf-fortify-rdonly-static with -Wl,-z,relro [BZ 33183]
This test requires relro_format be placed in the PT_GNU_RELRO segment.
The ELF linker enables -z relro support by default on all Linux targets
except FRV, HPPA, IA64 and MIPS. On these targets, we need to explicitly
link with -z relro to place relro_format in the PT_GNU_RELRO segment.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Makeconfig: The hash character # confuses old make, use $(dir instead of sed
Up to Make 4.2, # is treated as the start of a comment even in
function invocations. This leads to a syntax error. Fixed in Make 4.3,
but we still support versions back to 4.0 at the moment.
Tested on Gentoo (x86-64) and Debian (loongarch64)
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> Reviewed-by: Collin Funk <collin.funk1@gmail.com>
posix: Fix double-free after allocation failure in regcomp (bug 33185)
If a memory allocation failure occurs during bracket expression
parsing in regcomp, a double-free error may result.
Reported-by: Anastasia Belova <abelova@astralinux.ru> Co-authored-by: Paul Eggert <eggert@cs.ucla.edu> Reviewed-by: Andreas K. Huettel <dilfridge@gentoo.org>
Reason for revert: TCGETS etc. work to some extent on at least
a subset of architectures, so there is no pressing need to force
applications off them. Removal of the macros breaks building
the sanitizers, impacting both GCC and LLVM.
H. Peter Anvin [Sun, 13 Jul 2025 05:19:43 +0000 (22:19 -0700)]
termios: SPEED_MAX and BAUD_MAX constants
Add constants indicating the maximum values of speed_t and baud_t.
Hopefully if and when the baud_t interface is standardized then
BAUD_MAX will be included in the standardization from the start.
Historically, the __MAX_BAUD symbol has indicated the maximum speed_t
value on at least some platforms (including glibc). However, this
name would be problematic for future standardization, because it
confusingly implies a reference to baud_t, not speed_t, and it is
inconsistent with other limit symbols, which are all of the form *_MAX
(e.g. SIZE_MAX for size_t.)
[ v3: dropped leading underscores, leave __MAX_BAUD outside
#ifdef __USE_MISC since it is a legacy symbol, and
namespace-protected with a double underscore.
(Collin Funk, Adhermerval Zanella Netto) ]
[ v4: moved from __USE_MISC to __USE_GNU (Collin Funk) ]
Signed-off-by: "H. Peter Anvin" (Intel) <hpa@zytor.com> Reviewed-by: Collin Funk <collin.funk1@gmail.com>
H. Peter Anvin [Sun, 13 Jul 2025 05:19:42 +0000 (22:19 -0700)]
termios: move the baud_t interface from __USE_MISC to __USE_GNU
__USE_MISC refers to interfaces imported from BSD or System V, but the
baud_t interface is (at least for now) a GNU extension, so move it
from __USE_MISC to __USE_GNU.
Suggested-by: Collin Funk <collin.funk1@gmail.com> Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Reviewed-by: Collin Funk <collin.funk1@gmail.com>
H. Peter Anvin [Sun, 13 Jul 2025 02:20:04 +0000 (19:20 -0700)]
termios: manual: improve the explanation of various tty concepts
It is a lot easier to understand the meaning of the tty interface if
it is explained from the beginning as conceptually emulating an RS232
serial port. This greatly simplifies the discussions of specific
items like the meaning of line speed.
Distinguish between "modem disconnect request" (deasserting DTR) and
"modem disconnect" (DCD deasserted). Conflating the two terms is
confusing, especially for non-RS232 devices. In particular, on most
systems, a pseudo-terminal will *not* respond to a modem disconnect
request by triggering a modem disconnect event for the purpose of the
HUPCL flag.
It is not necessarily true that the line speed has no effect on
non-serial port devices: e.g. an SPI port may interpret it as the
clock frequency to use; however, SPI does not use asynchronous framing
bits, instead synchronization is handled by the SS# wire. Similarly,
it is common but not by any means universal for interfaces that employ
various forms of fixed data to symbol rate encodings to encode the
data link layer bit rate rather than the physical symbol rate, which
may be higher (e.g. 8B10B) or lower (e.g. QAM/Trellis), without the
encoding or framing overhead.
Finally, a handful of devices use the line rate for entirely
nonstandard purposes. One example is Arduino USB interfaces, which
often interprets changing the baud rate to 1200 baud as a command to
reset the device.
[ v2: removed a bogus stray chunk from editing ]
Signed-off-by: H. Peter Anvin <hpa@zytor.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
H.J. Lu [Sat, 19 Jul 2025 00:03:04 +0000 (17:03 -0700)]
io/tst-stat.c: Use a temporary directory for symlink test
Call support_create_temp_directory to create a temporary directory for
symlink test, instead of a fixed file in the glibc source tree, to avoid
the race condition when there are more than one glibc tests running at the
same time with the same glibc source tree. This fixes BZ #33178.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Andreas K. Huettel <dilfridge@gentoo.org>
elf: Initialize GLRO (dl_read_only_area) after static dlopen (bug 33139)
The _dl_read_only_area function in the uninitialized ld.so after
static dlopen is not able to find anything. Instead, we need to
redirect to the code from the statically linked main program.
H.J. Lu [Thu, 17 Jul 2025 23:00:42 +0000 (16:00 -0700)]
x86-64: Properly compile ISA optimized modf and modff
There are 3 variants of modf and modff: SSE2, SSE4.1 and AVX. s_modf.c
and s_modff.c include the generic implementation compiled with the minimum
x86 ISA level. The IFUNC selector is used only if the minimum ISA level
is less than AVX. SSE4.1 variant is included only if the ISA level is
less than SSE4.1. AVX variant is included only the ISA level is less than
AVX.
AVX variant should be compiled with -mavx, not -msse2avx -DSSE2AVX which
are used to encode SSE assembly sources with EVEX encoding.
The routines that are shared between libc and libm should use different
rules to avoid using the same MODULE_NAME, to avoid potential issues
like BZ #33165 where __stack_chk_fail not being routed to the internal
symbol.
Tested with -march=x86-64, -march=x86-64-v2, -march=x86-64-v3 and
-march=x86-64-v4.
H.J. Lu [Thu, 17 Jul 2025 00:17:34 +0000 (17:17 -0700)]
x86-64: Compile ISA versions of modf/modff with -fno-stack-protector
Since modf and modff are compiled into both libc and libm, when glibc is
configured with --enable-stack-protector=all, ISA versions of modf and
modff should be compiled with -fno-stack-protector to avoid calling
__stack_chk_fail via PLT in libc.so.
This fixes BZ #33165.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Andreas K. Huettel <dilfridge@gentoo.org>
Enable SFrame stack track information. The --enable-sframe option
allows the glibc build to compile with SFrame stack track
information. Thus, enabling glibc's backtrace to work within glibc.
Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com> Reviewed-by: DJ Delorie <dj@redhat.com> Reviewed-by: Sam James <sam@gentoo.org>
This patch adds the necessary bits to enable stack tracing using
SFrame. In the case the new SFrame stack tracing procedure doesn't
find SFrame related info, the stack tracing falls back on default
Dwarf implementation.
The new SFrame stack tracing procedure is added to debug/backtrace.c
file, the support functions are added in sysdeps folder, namely
sframe.h, read-sframe.c and read-sfame.h.
Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com> Reviewed-by: DJ Delorie <dj@redhat.com>
elf: Add SFrame support to _dl_find_object function
The SFrame provides information to be able to do stack trace is now
well defined and implemented in Binutils 2.41. The format simply
contains enough information to be able to do stack trace given a
program counter (PC) value, the stack pointer, and the frame pointer.
The SFrame information is stored in a .sframe ELF section, which is
loaded into its own PT_GNU_SFRAME segment. We consider for this support
SFrame version 2.
This patch adds the bits to _dl_find_object to recognize and store in
struct dl_find_object the necessary info about SFrame section.
For x86_64-v1 the optimization is done through a new ifunc selector.
The avx is to follow other SSE4_1 optimization (like trunc) to avoid
the ifunc for x86_64-v3.
Checked on x86_64-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Undefine TCGETS, TCGETS2, and related ioctl constants in the installed
headers. Extract the correct constants (using the kernel type
definitions) automatically from the UAPI headers. The kernel
constants are available under KERNEL_* names during the glibc build,
computed using assembler constant extraction mechanism.
Alpha may have to use TCGETS instead of TCGETS2 because TCTGETS2
became available in Linux 4.20 only. Introduce ARCH_TCGETS to make
this choice explict.
To support emulation on powerpc, glibc versions of the termios
constants are added to the emulation code in internal-ioctl.h.
Andreas Schwab [Thu, 10 Jul 2025 07:19:38 +0000 (09:19 +0200)]
Remove termios2 ioctl defintions from public headers
The use of the termios2 ioctl interface is an implementation detail which
should not bleed into public headers. Remove the PowerPC version of
<bits/ioctls.h> and define the termios2 ioctl numbers in <termios_arch.h>
instead. Also remove the include check from there which is unneeded in an
internal header.
Makeconfig: Add libgcc directory to rtld-prefix search path
* This needs to be done twice, for test runs with and without
--enable-hardcoded-path-in-tests
* Also, we need to query the used $(CC) for the library location.
* The container tests run ldd and dump the list of needed libraries, then
copy these into the container.
* Without this patch, ldd may not find libgcc_s.so, resulting in"not found"
output and no copying of the library.
* With this patch, the library is picked up independent of its location (as
long as the proper directory is provided) and copied into the testroot.
* This does not mean yet that ld.so in the testroot actually finds it.
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Stefan Liebler [Tue, 8 Jul 2025 13:06:45 +0000 (15:06 +0200)]
Mark support for lock elision as deprecated.
As discussed here:
https://sourceware.org/pipermail/libc-alpha/2025-July/168492.html
The support for TX lock elision of pthread mutexes is deprecated on
all architectures and will be removed in the next release. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Matteo Croce [Tue, 24 Jun 2025 16:40:13 +0000 (18:40 +0200)]
fstat: add test and documentation for an edge case.
The fstatat behaviour when the target is a dangling symlink is different
if flags contains AT_SYMLINK_NOFOLLOW or not.
Add a test for this and document it.
projects / thirdparty / glibc.git / log
