Paul Eggert [Wed, 13 May 2026 18:08:34 +0000 (11:08 -0700)]
timezone: sync to tzdb 2026b
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
xiejiamei [Sat, 9 May 2026 06:23:09 +0000 (14:23 +0800)]
x86: Lower non-temporal copy threshold for Hygon
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.
Rocket Ma [Wed, 13 May 2026 16:12:42 +0000 (09:12 -0700)]
libio: Fix fmemopen_write on appending mode (BZ 34006)
* 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>
elf: Defer all IRELATIVE relocations until after PLT setup
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.
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.
Avinal Kumar [Tue, 5 May 2026 11:28:25 +0000 (16:58 +0530)]
intl: Fix memory leak in _nl_find_domain on allocation failure
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>
Avinal Kumar [Tue, 5 May 2026 15:11:42 +0000 (20:41 +0530)]
intl: Remove pre-C99 fallbacks from plural-exp.c
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>
Avinal Kumar [Tue, 5 May 2026 15:11:41 +0000 (20:41 +0530)]
intl: Remove PRI_MACROS_BROKEN from loadmsgcat.c
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>
Avinal Kumar [Tue, 5 May 2026 15:11:40 +0000 (20:41 +0530)]
intl: Remove IN_LIBGLOCALE dead code
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>
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.
stdio-common: Silence clang -Wfortify-source warning in tst-vfscanf-bz34008
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.
elf: Batch program-header reads in _dl_map_segments (oversight fix)
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>
Shamil Abdulaev [Wed, 13 May 2026 05:52:40 +0000 (07:52 +0200)]
libio: Fix race in _IO_new_file_init_internal initialization order [BZ #33785]
_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.
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.
libio: Fix gconv module reference counter overflow in swscanf
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.
elf: Eliminate alloca for program-header table in the ELF loader
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>
elf: Fix stack overflow in _dl_map_object_from_fd with large e_phnum (BZ 26577)
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>
Avinal Kumar [Mon, 4 May 2026 17:22:06 +0000 (22:52 +0530)]
intl: Add tests for plural expression hardening
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.
Avinal Kumar [Mon, 4 May 2026 17:22:05 +0000 (22:52 +0530)]
intl: Import plural expression hardening from GNU gettext
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
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.
Yao Zihong [Tue, 5 May 2026 21:22:29 +0000 (16:22 -0500)]
riscv: Add RVV strncmp for both multiarch and non-multiarch builds
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>
Yao Zihong [Tue, 5 May 2026 21:12:37 +0000 (16:12 -0500)]
riscv: Add RVV strcmp for both multiarch and non-multiarch builds
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>
Yury Khrustalev [Wed, 6 May 2026 12:29:56 +0000 (13:29 +0100)]
support: add support_ptr_after_free
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.
Rocket Ma [Sat, 18 Apr 2026 06:48:41 +0000 (23:48 -0700)]
stdio-common: Fix buffer overflow in scanf %mc [BZ #34008]
* 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>
Uros Bizjak [Wed, 6 May 2026 15:07:54 +0000 (17:07 +0200)]
i386: Replace inline asm rotates in pointer_guard with stdc_rotate_{left,right}
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.
Uros Bizjak [Wed, 6 May 2026 15:05:46 +0000 (17:05 +0200)]
x86_64: Replace inline asm rotates in pointer_guard with stdc_rotate_{left,right}
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.
Carlos O'Donell [Thu, 7 May 2026 14:41:36 +0000 (10:41 -0400)]
Drop "(C) YYYY" from DCO'd contributions.
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.
Rocket Ma [Sat, 2 May 2026 03:39:07 +0000 (20:39 -0700)]
libio: Fix ungetwc operating on byte stream [BZ #33998]
* 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>
Uros Bizjak [Wed, 6 May 2026 13:15:35 +0000 (15:15 +0200)]
stdlib: add missing stdc_rotate_right_ull alias when builtin is available
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: 331c7a4cd0ee ("stdbit: Fix builtin name used in __glibc_has_builtin check for rotate_right") Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Uros Bizjak [Wed, 6 May 2026 09:21:39 +0000 (11:21 +0200)]
stdbit: Fix builtin name used in __glibc_has_builtin check for rotate_right
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.
Yao Zihong [Thu, 30 Apr 2026 20:15:36 +0000 (15:15 -0500)]
riscv: Add RVV strlen for both multiarch and non-multiarch builds
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>
Jiho Lee [Wed, 29 Apr 2026 01:00:14 +0000 (10:00 +0900)]
localedata: update LC_ADDRESS and LC_NAME for ko_KR
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.
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>
Petr Menšík [Thu, 16 Oct 2025 14:18:23 +0000 (16:18 +0200)]
Return different exit codes when gai_result is > -100
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>
Petr Menšík [Thu, 16 Oct 2025 14:18:21 +0000 (16:18 +0200)]
nss: Add verbose flag to getent tool
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>
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.
The URL https://www.gnu.org/software/libc/bugs.html now redirects to
a page with no bug-reporting instructions. Point to the glibc wiki
Bugzilla Procedures page instead.
Signed-off-by: Shamil Abdulaev <ashamil435@gmail.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.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.
Rocket Ma [Fri, 24 Apr 2026 17:27:59 +0000 (10:27 -0700)]
misc: Optimize getusershell.c
* 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>
Stefan Liebler [Thu, 23 Apr 2026 12:43:33 +0000 (14:43 +0200)]
Remove EXIT_UNSUPPORTED in stdlib/test-bz22786 if path is NULL
With commit 6c3a8a9d868a8deddf0d6dcc785b6d120de90523 (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 3bad2358d67d371497079bba4f8eca9c0096f4e2
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 b01debcd8f5229860b3224ea135b1b8456281cee
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 855a67c3cc81be4fc806c66e3e01b53e352a4e9f 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>
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.
posix: fix false regex match with backrefs and $ anchor
This fixes the $ anchor being ignored in the following grep command:
$ grep -E '^(.?)(.?).?\2\1$' <<< ab
ab
However, the regular expression should only match palindromes.
This patch is mostly copied from a commit in Gnulib from Jim Meyering
[1], and a followup commit by Paul Eggert [2]. It was found by Ed Morton
in GNU sed [3].
Yao Zihong [Tue, 21 Apr 2026 19:58:10 +0000 (14:58 -0500)]
riscv: Add RVV memcpy for both multiarch and non-multiarch builds
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>
Yury Khrustalev [Wed, 25 Mar 2026 10:04:19 +0000 (10:04 +0000)]
support: add support_address_diff function
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
Yao Zihong [Mon, 20 Apr 2026 21:19:08 +0000 (16:19 -0500)]
riscv: Add RVV strcpy for both multiarch and non-multiarch builds
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>
Stefan Liebler [Tue, 21 Apr 2026 12:50:15 +0000 (14:50 +0200)]
s390: Remove Wno-CFLAGS for rtld.c/dl-load.c/dl-reloc.c
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>
Pierre Blanchard [Wed, 15 Apr 2026 08:32:44 +0000 (08:32 +0000)]
AArch64: Implement AdvSIMD and SVE powr(f) routines
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.
Pierre Blanchard [Wed, 15 Apr 2026 08:32:41 +0000 (08:32 +0000)]
AArch64: Improve AdvSIMD and SVE pow(f).
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.
Yao Zihong [Wed, 18 Feb 2026 21:12:09 +0000 (15:12 -0600)]
riscv: Add RVV strcat for both multiarch and non-multiarch builds
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>
Stefan Liebler [Thu, 9 Apr 2026 08:47:09 +0000 (10:47 +0200)]
s390: Move files out of s390-64 folders
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>
Stefan Liebler [Thu, 9 Apr 2026 08:47:08 +0000 (10:47 +0200)]
s390: Switch to common-code headers
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>
Stefan Liebler [Thu, 9 Apr 2026 08:47:07 +0000 (10:47 +0200)]
s390: Remove s390-32 specific code in non s390-32 specific files
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>
Stefan Liebler [Thu, 9 Apr 2026 08:47:06 +0000 (10:47 +0200)]
s390: Remove support for s390-32.
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 638d437dbf9c68e40986edaa9b0d1c2e72a1ae81
"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>
WANG Rui [Mon, 20 Apr 2026 10:54:13 +0000 (10:54 +0000)]
elf: Add test for THP alignment of large load segments
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>
Use pending character state in IBM1390, IBM1399 character sets (CVE-2026-4046)
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>
WANG Rui [Tue, 14 Apr 2026 15:26:58 +0000 (15:26 +0000)]
loongarch: Enable THP-aligned load segments by default on 64-bit
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.
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>
WANG Rui [Tue, 14 Apr 2026 15:24:39 +0000 (15:24 +0000)]
elf: Align large load segments to PMD huge page size for THP
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>
WANG Rui [Tue, 14 Apr 2026 15:17:46 +0000 (15:17 +0000)]
tunables: Add glibc.elf.thp tunable for THP-aware segment alignment
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>
WANG Rui [Tue, 14 Apr 2026 15:16:07 +0000 (15:16 +0000)]
elf: Introduce _dl_map_segment_align hook for segment alignment tuning
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>
WANG Rui [Tue, 14 Apr 2026 15:14:33 +0000 (15:14 +0000)]
elf: Remove redundant _dl_map_segments declaration from dl-load.h
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.
projects / thirdparty / glibc.git / log
