about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* elf: Only process multiple tunable once (BZ 31686) release/2.39/masterAdhemerval Zanella47 hours4-12/+84
| | | | | | | | | | | | | | | | | | | | | | | | | The 680c597e9c3 commit made loader reject ill-formatted strings by first tracking all set tunables and then applying them. However, it does not take into consideration if the same tunable is set multiple times, where parse_tunables_string appends the found tunable without checking if it was already in the list. It leads to a stack-based buffer overflow if the tunable is specified more than the total number of tunables. For instance: GLIBC_TUNABLES=glibc.malloc.check=2:... (repeat over the number of total support for different tunable). Instead, use the index of the tunable list to get the expected tunable entry. Since now the initial list is zero-initialized, the compiler might emit an extra memset and this requires some minor adjustment on some ports. Checked on x86_64-linux-gnu and aarch64-linux-gnu. Reported-by: Yuto Maeda <maeda@cyberdefense.jp> Reported-by: Yutaro Shimizu <shimizu@cyberdefense.jp> Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit bcae44ea8536b30a7119c0986ff5692bddacb672)
* Add a test to check for duplicate definitions in the static libraryGabi Falk5 days1-0/+7
| | | | | | | | | | | | This change follows two previous fixes addressing multiple definitions of __memcpy_chk and __mempcpy_chk functions on i586, and __memmove_chk and __memset_chk functions on i686. The test is intended to prevent such issues from occurring in the future. Signed-off-by: Gabi Falk <gabifalk@gmx.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> (cherry picked from commit ded2e0753e9c46debeb2e0d26c5e560d2581d314)
* i686: Fix multiple definitions of __memmove_chk and __memset_chkGabi Falk5 days2-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c73c96a4a1af1326df7f96eec58209e1e04066d8 updated memcpy.S and mempcpy.S, but omitted memmove.S and memset.S. As a result, the static library built as PIC, whether with or without multiarch support, contains two definitions for each of the __memmove_chk and __memset_chk symbols. /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../i686-pc-linux-gnu/bin/ld: /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../lib/libc.a(memset-ia32.o): in function `__memset_chk': /var/tmp/portage/sys-libs/glibc-2.39-r3/work/glibc-2.39/string/../sysdeps/i386/i686/memset.S:32: multiple definition of `__memset_chk'; /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../lib/libc.a(memset_chk.o):/var/tmp/portage/sys-libs/glibc-2.39-r3/work/glibc-2.39/debug/../sysdeps/i386/i686/multiarch/memset_chk.c:24: first defined here After this change, regardless of PIC options, the static library, built for i686 with multiarch contains implementations of these functions respectively from debug/memmove_chk.c and debug/memset_chk.c, and without multiarch contains implementations of these functions respectively from sysdeps/i386/memmove_chk.S and sysdeps/i386/memset_chk.S. This ensures that memmove and memset won't pull in __chk_fail and the routines it calls. Reported-by: Sam James <sam@gentoo.org> Tested-by: Sam James <sam@gentoo.org> Fixes: c73c96a4a1 ("i686: Fix build with --disable-multiarch") Signed-off-by: Gabi Falk <gabifalk@gmx.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> (cherry picked from commit 5a2cf833f5772d6c37c7adac388dd9af9cc1c4b9)
* i586: Fix multiple definitions of __memcpy_chk and __mempcpy_chkGabi Falk5 days1-1/+1
| | | | | | | | | | | | | | | | | /home/bmg/install/compilers/x86_64-linux-gnu/lib/gcc/x86_64-glibc-linux-gnu/13.2.1/../../../../x86_64-glibc-linux-gnu/bin/ld: /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(memcpy_chk.o): in function `__memcpy_chk': /home/bmg/src/glibc/debug/../sysdeps/i386/memcpy_chk.S:29: multiple definition of `__memcpy_chk';/home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(memcpy.o):/home/bmg/src/glibc/string/../sysdeps/i386/i586/memcpy.S:31: first defined here /home/bmg/install/compilers/x86_64-linux-gnu/lib/gcc/x86_64-glibc-linux-gnu/13.2.1/../../../../x86_64-glibc-linux-gnu/bin/ld: /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(mempcpy_chk.o): in function `__mempcpy_chk': /home/bmg/src/glibc/debug/../sysdeps/i386/mempcpy_chk.S:28: multiple definition of `__mempcpy_chk'; /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(mempcpy.o):/home/bmg/src/glibc/string/../sysdeps/i386/i586/memcpy.S:31: first defined here After this change, the static library built for i586, regardless of PIC options, contains implementations of these functions respectively from sysdeps/i386/memcpy_chk.S and sysdeps/i386/mempcpy_chk.S. This ensures that memcpy and mempcpy won't pull in __chk_fail and the routines it calls. Reported-by: Florian Weimer <fweimer@redhat.com> Signed-off-by: Gabi Falk <gabifalk@gmx.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> (cherry picked from commit 0fdf4ba48ccce5abf567340b0ab8fa8ed8a9bc6e)
* Revert "i586: Fix multiple definitions of __memcpy_chk and __mempcpy_chk"Sam James5 days1-1/+1
| | | | | | | | | | This reverts commit 3148714ab61ad61281bae5a30f530d637034ac3b. I had the wrong cherry-pick reference (the commit content is right; it's just referring to a base that isn't upstream), but let's revert and reapply for clarity. Signed-off-by: Sam James <sam@gentoo.org>
* Revert "i686: Fix multiple definitions of __memmove_chk and __memset_chk"Sam James5 days2-2/+2
| | | | | | | | | | This reverts commit ad92c483a4bd34db1cfb3eb625212ea64848244f. I had the wrong cherry-pick reference (the commit content is right; it's just referring to a base that isn't upstream), but let's revert and reapply for clarity. Signed-off-by: Sam James <sam@gentoo.org>
* Revert "Add a test to check for duplicate definitions in the static library"Sam James5 days1-7/+0
| | | | | | | | | | This reverts commit ff110b2591f0bdeccd121c3726af19c62d6fb184. I had the wrong cherry-pick reference (the commit content is right; it's just referring to a base that isn't upstream), but let's revert and reapply for clarity. Signed-off-by: Sam James <sam@gentoo.org>
* Add a test to check for duplicate definitions in the static libraryGabi Falk5 days1-0/+7
| | | | | | | | | | | | This change follows two previous fixes addressing multiple definitions of __memcpy_chk and __mempcpy_chk functions on i586, and __memmove_chk and __memset_chk functions on i686. The test is intended to prevent such issues from occurring in the future. Signed-off-by: Gabi Falk <gabifalk@gmx.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> (cherry picked from commit ded2e0753e9c46debeb2e0d26c5e560d2581d314)
* i686: Fix multiple definitions of __memmove_chk and __memset_chkGabi Falk5 days2-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c73c96a4a1af1326df7f96eec58209e1e04066d8 updated memcpy.S and mempcpy.S, but omitted memmove.S and memset.S. As a result, the static library built as PIC, whether with or without multiarch support, contains two definitions for each of the __memmove_chk and __memset_chk symbols. /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../i686-pc-linux-gnu/bin/ld: /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../lib/libc.a(memset-ia32.o): in function `__memset_chk': /var/tmp/portage/sys-libs/glibc-2.39-r3/work/glibc-2.39/string/../sysdeps/i386/i686/memset.S:32: multiple definition of `__memset_chk'; /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../lib/libc.a(memset_chk.o):/var/tmp/portage/sys-libs/glibc-2.39-r3/work/glibc-2.39/debug/../sysdeps/i386/i686/multiarch/memset_chk.c:24: first defined here After this change, regardless of PIC options, the static library, built for i686 with multiarch contains implementations of these functions respectively from debug/memmove_chk.c and debug/memset_chk.c, and without multiarch contains implementations of these functions respectively from sysdeps/i386/memmove_chk.S and sysdeps/i386/memset_chk.S. This ensures that memmove and memset won't pull in __chk_fail and the routines it calls. Reported-by: Sam James <sam@gentoo.org> Tested-by: Sam James <sam@gentoo.org> Fixes: c73c96a4a1 ("i686: Fix build with --disable-multiarch") Signed-off-by: Gabi Falk <gabifalk@gmx.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> (cherry picked from commit 5a2cf833f5772d6c37c7adac388dd9af9cc1c4b9)
* i586: Fix multiple definitions of __memcpy_chk and __mempcpy_chkGabi Falk5 days1-1/+1
| | | | | | | | | | | | | | | | | /home/bmg/install/compilers/x86_64-linux-gnu/lib/gcc/x86_64-glibc-linux-gnu/13.2.1/../../../../x86_64-glibc-linux-gnu/bin/ld: /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(memcpy_chk.o): in function `__memcpy_chk': /home/bmg/src/glibc/debug/../sysdeps/i386/memcpy_chk.S:29: multiple definition of `__memcpy_chk';/home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(memcpy.o):/home/bmg/src/glibc/string/../sysdeps/i386/i586/memcpy.S:31: first defined here /home/bmg/install/compilers/x86_64-linux-gnu/lib/gcc/x86_64-glibc-linux-gnu/13.2.1/../../../../x86_64-glibc-linux-gnu/bin/ld: /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(mempcpy_chk.o): in function `__mempcpy_chk': /home/bmg/src/glibc/debug/../sysdeps/i386/mempcpy_chk.S:28: multiple definition of `__mempcpy_chk'; /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(mempcpy.o):/home/bmg/src/glibc/string/../sysdeps/i386/i586/memcpy.S:31: first defined here After this change, the static library built for i586, regardless of PIC options, contains implementations of these functions respectively from sysdeps/i386/memcpy_chk.S and sysdeps/i386/mempcpy_chk.S. This ensures that memcpy and mempcpy won't pull in __chk_fail and the routines it calls. Reported-by: Florian Weimer <fweimer@redhat.com> Signed-off-by: Gabi Falk <gabifalk@gmx.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> (cherry picked from commit 789894a2f554d4503ecb2f13b2b4e93e43414f33)
* time: Allow later version licensing.Carlos O'Donell6 days4-4/+4
| | | | | | | | | | | | | | | | | The FSF's Licensing and Compliance Lab noted a discrepancy in the licensing of several files in the glibc package. When timespect_get.c was impelemented the license did not include the standard ", or (at your option) any later version." text. Change the license in timespec_get.c and all copied files to match the expected license. This change was previously approved in principle by the FSF in RT ticket #1316403. And a similar instance was fixed in commit 46703efa02f6ddebce5ee54c92f7c32598de0de6. (cherry picked from commit 91695ee4598b39d181ab8df579b888a8863c4cab)
* nscd: Use time_t for return type of addgetnetgrentXFlorian Weimer7 days1-2/+2
| | | | | | | | | | | | Using int may give false results for future dates (timeouts after the year 2028). Fixes commit 04a21e050d64a1193a6daab872bca2528bda44b ("CVE-2024-33601, CVE-2024-33602: nscd: netgroup: Use two buffers in addgetnetgrentX (bug 31680)"). Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 4bbca1a44691a6e9adcee5c6798a707b626bc331)
* login: structs utmp, utmpx, lastlog _TIME_BITS independence (bug 30701)Florian Weimer7 days18-22/+165
| | | | | | | | | | These structs describe file formats under /var/log, and should not depend on the definition of _TIME_BITS. This is achieved by defining __WORDSIZE_TIME64_COMPAT32 to 1 on 32-bit ports that support 32-bit time_t values (where __time_t is 32 bits). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 9abdae94c7454c45e02e97e4ed1eb1b1915d13d8)
* login: Check default sizes of structs utmp, utmpx, lastlogFlorian Weimer7 days17-1/+88
| | | | | | | | | The default <utmp-size.h> is for ports with a 64-bit time_t. Ports with a 32-bit time_t or with __WORDSIZE_TIME64_COMPAT32=1 need to override it. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 4d4da5aab936504b2d3eca3146e109630d9093c4)
* elf: Also compile dl-misc.os with $(rtld-early-cflags)H.J. Lu2024-04-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also compile dl-misc.os with $(rtld-early-cflags) to avoid Program received signal SIGILL, Illegal instruction. 0x00007ffff7fd36ea in _dl_strtoul (nptr=nptr@entry=0x7fffffffe2c9 "2", endptr=endptr@entry=0x7fffffffd728) at dl-misc.c:156 156 bool positive = true; (gdb) bt #0 0x00007ffff7fd36ea in _dl_strtoul (nptr=nptr@entry=0x7fffffffe2c9 "2", endptr=endptr@entry=0x7fffffffd728) at dl-misc.c:156 #1 0x00007ffff7fdb1a9 in tunable_initialize ( cur=cur@entry=0x7ffff7ffbc00 <tunable_list+2176>, strval=strval@entry=0x7fffffffe2c9 "2", len=len@entry=1) at dl-tunables.c:131 #2 0x00007ffff7fdb3a2 in parse_tunables (valstring=<optimized out>) at dl-tunables.c:258 #3 0x00007ffff7fdb5d9 in __GI___tunables_init (envp=0x7fffffffdd58) at dl-tunables.c:288 #4 0x00007ffff7fe44c3 in _dl_sysdep_start ( start_argptr=start_argptr@entry=0x7fffffffdcb0, dl_main=dl_main@entry=0x7ffff7fe5f80 <dl_main>) at ../sysdeps/unix/sysv/linux/dl-sysdep.c:110 #5 0x00007ffff7fe5cae in _dl_start_final (arg=0x7fffffffdcb0) at rtld.c:494 #6 _dl_start (arg=0x7fffffffdcb0) at rtld.c:581 #7 0x00007ffff7fe4b38 in _start () (gdb) when setting GLIBC_TUNABLES in glibc compiled with APX. Reviewed-by: Florian Weimer <fweimer@redhat.com> (cherry picked from commit 049b7684c912dd32b67b1b15b0f43bf07d5f512e)
* CVE-2024-33601, CVE-2024-33602: nscd: netgroup: Use two buffers in ↵Florian Weimer2024-04-251-98/+121
| | | | | | | | | | | | | | | | | | addgetnetgrentX (bug 31680) This avoids potential memory corruption when the underlying NSS callback function does not use the buffer space to store all strings (e.g., for constant strings). Instead of custom buffer management, two scratch buffers are used. This increases stack usage somewhat. Scratch buffer allocation failure is handled by return -1 (an invalid timeout value) instead of terminating the process. This fixes bug 31679. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit c04a21e050d64a1193a6daab872bca2528bda44b)
* CVE-2024-33600: nscd: Avoid null pointer crashes after notfound response ↵Florian Weimer2024-04-251-4/+7
| | | | | | | | | | | | | | | | | | (bug 31678) The addgetnetgrentX call in addinnetgrX may have failed to produce a result, so the result variable in addinnetgrX can be NULL. Use db->negtimeout as the fallback value if there is no result data; the timeout is also overwritten below. Also avoid sending a second not-found response. (The client disconnects after receiving the first response, so the data stream did not go out of sync even without this fix.) It is still beneficial to add the negative response to the mapping, so that the client can get it from there in the future, instead of going through the socket. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit b048a482f088e53144d26a61c390bed0210f49f2)
* CVE-2024-33600: nscd: Do not send missing not-found response in ↵Florian Weimer2024-04-251-8/+6
| | | | | | | | | | addgetnetgrentX (bug 31678) If we failed to add a not-found response to the cache, the dataset point can be null, resulting in a null pointer dereference. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 7835b00dbce53c3c87bbbb1754a95fb5e58187aa)
* CVE-2024-33599: nscd: Stack-based buffer overflow in netgroup cache (bug 31677)Florian Weimer2024-04-251-2/+3
| | | | | | | | Using alloca matches what other caches do. The request length is bounded by MAXKEYLEN. Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 87801a8fd06db1d654eea3e4f7626ff476a9bdaa)
* x86: Define MINIMUM_X86_ISA_LEVEL in config.h [BZ #31676]H.J. Lu2024-04-254-1/+18
| | | | | | | | | | | | | | | | | | | | | Define MINIMUM_X86_ISA_LEVEL at configure time to avoid /usr/bin/ld: …/build/elf/librtld.os: in function `init_cpu_features': …/git/elf/../sysdeps/x86/cpu-features.c:1202: undefined reference to `_dl_runtime_resolve_fxsave' /usr/bin/ld: …/build/elf/librtld.os: relocation R_X86_64_PC32 against undefined hidden symbol `_dl_runtime_resolve_fxsave' can not be used when making a shared object /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status when glibc is built with -march=x86-64-v3 and configured with --with-rtld-early-cflags=-march=x86-64, which is used to allow ld.so to print an error message on unsupported CPUs: Fatal glibc error: CPU does not support x86-64-v3 This fixes BZ #31676. Reviewed-by: Sunil K Pandey <skpgkp2@gmail.com> (cherry picked from commit 46c999741340ea559784c20a45077955b50aca43)
* i386: ulp update for SSE2 --disable-multi-arch configurationsFlorian Weimer2024-04-251-0/+1
| | | | (cherry picked from commit 3a3a4497421422aa854c855cbe5110ca7d598ffc)
* nptl: Fix tst-cancel30 on kernels without ppoll_time64 supportFlorian Weimer2024-04-251-4/+11
| | | | | | | | | Fall back to ppoll if ppoll_time64 fails with ENOSYS. Fixes commit 370da8a121c3ba9eeb2f13da15fc0f21f4136b25 ("nptl: Fix tst-cancel30 on sparc64"). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit f4724843ada64a51d66f65d3199fe431f9d4c254)
* iconv: ISO-2022-CN-EXT: fix out-of-bound writes when writing escape sequence ↵Charles Fol2024-04-173-1/+144
| | | | | | | | | | | | | | | | | | (CVE-2024-2961) ISO-2022-CN-EXT uses escape sequences to indicate character set changes (as specified by RFC 1922). While the SOdesignation has the expected bounds checks, neither SS2designation nor SS3designation have its; allowing a write overflow of 1, 2, or 3 bytes with fixed values: '$+I', '$+J', '$+K', '$+L', '$+M', or '$*H'. Checked on aarch64-linux-gnu. Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit f9dc609e06b1136bb0408be9605ce7973a767ada)
* x86_64: Exclude SSE, AVX and FMA4 variants in libm multiarchSunil K Pandey2024-04-1462-295/+953
| | | | | | | | | | | | | | | | | | | | When glibc is built with ISA level 3 or higher by default, the resulting glibc binaries won't run on SSE or FMA4 processors. Exclude SSE, AVX and FMA4 variants in libm multiarch when ISA level 3 or higher is enabled by default. When glibc is built with ISA level 2 enabled by default, only keep SSE4.1 variant. Fixes BZ 31335. NB: elf/tst-valgrind-smoke test fails with ISA level 4, because valgrind doesn't support AVX512 instructions: https://bugs.kde.org/show_bug.cgi?id=383010 Reviewed-by: H.J. Lu <hjl.tools@gmail.com> (cherry picked from commit 9f78a7c1d0963282608da836b840f0d5ae1c478e)
* Apply the Makefile sorting fixH.J. Lu2024-04-145-57/+57
| | | | | | Apply the Makefile sorting fix generated by sort-makefile-lines.py. (cherry picked from commit ef7f4b1fef67430a8f3cfc77fa6aada2add851d7)
* powerpc: Fix ld.so address determination for PCREL mode (bug 31640)Florian Weimer2024-04-141-0/+19
| | | | | | | | | This seems to have stopped working with some GCC 14 versions, which clobber r2. With other compilers, the kernel-provided r2 value is still available at this point. Reviewed-by: Peter Bergner <bergner@linux.ibm.com> (cherry picked from commit 14e56bd4ce15ac2d1cc43f762eb2e6b83fec1afe)
* x86-64: Simplify minimum ISA check ifdef conditional with ifSunil K Pandey2024-04-131-11/+8
| | | | | | | | | | Replace minimum ISA check ifdef conditional with if. Since MINIMUM_X86_ISA_LEVEL and AVX_X86_ISA_LEVEL are compile time constants, compiler will perform constant folding optimization, getting same results. Reviewed-by: H.J. Lu <hjl.tools@gmail.com> (cherry picked from commit b6e3898194bbae78910bbe9cd086937014961e45)
* x86-64: Don't use SSE resolvers for ISA level 3 or aboveH.J. Lu2024-04-132-12/+20
| | | | | | | | | | | | | | | | | | When glibc is built with ISA level 3 or above enabled, SSE resolvers aren't available and glibc fails to build: ld: .../elf/librtld.os: in function `init_cpu_features': .../elf/../sysdeps/x86/cpu-features.c:1200:(.text+0x1445f): undefined reference to `_dl_runtime_resolve_fxsave' ld: .../elf/librtld.os: relocation R_X86_64_PC32 against undefined hidden symbol `_dl_runtime_resolve_fxsave' can not be used when making a shared object /usr/local/bin/ld: final link failed: bad value For ISA level 3 or above, don't use _dl_runtime_resolve_fxsave nor _dl_tlsdesc_dynamic_fxsave. This fixes BZ #31429. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit befe2d3c4dec8be2cdd01a47132e47bdb7020922)
* AArch64: Check kernel version for SVE ifuncsWilco Dijkstra2024-04-095-2/+53
| | | | | | | | | | | | | | | | | Old Linux kernels disable SVE after every system call. Calling the SVE-optimized memcpy afterwards will then cause a trap to reenable SVE. As a result, applications with a high use of syscalls may run slower with the SVE memcpy. This is true for kernels between 4.15.0 and before 6.2.0, except for 5.14.0 which was patched. Avoid this by checking the kernel version and selecting the SVE ifunc on modern kernels. Parse the kernel version reported by uname() into a 24-bit kernel.major.minor value without calling any library functions. If uname() is not supported or if the version format is not recognized, assume the kernel is modern. Tested-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com> (cherry picked from commit 2e94e2f5d2bf2de124c8ad7da85463355e54ccb2)
* aarch64: fix check for SVE support in assemblerSzabolcs Nagy2024-04-092-4/+6
| | | | | | | | | | | | | | Due to GCC bug 110901 -mcpu can override -march setting when compiling asm code and thus a compiler targetting a specific cpu can fail the configure check even when binutils gas supports SVE. The workaround is that explicit .arch directive overrides both -mcpu and -march, and since that's what the actual SVE memcpy uses the configure check should use that too even if the GCC issue is fixed independently. Reviewed-by: Florian Weimer <fweimer@redhat.com> (cherry picked from commit 73c26018ed0ecd9c807bb363cc2c2ab4aca66a82)
* aarch64/fpu: Sync libmvec routines from 2.39 and before with AORJoe Ramsay2024-04-0918-105/+111
| | | | | | | | | This includes a fix for big-endian in AdvSIMD log, some cosmetic changes, and numerous small optimisations mainly around inlining and using indexed variants of MLA intrinsics. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit e302e1021391d13a9611ba3a910df128830bd19e)
* i386: Use generic memrchr in libc (bug 31316)Florian Weimer2024-04-072-1/+1
| | | | | | | | | Before this change, we incorrectly used the SSE2 variant in the implementation, without checking that the system actually supports SSE2. Tested-by: Sam James <sam@gentoo.org> (cherry picked from commit 0d9166c2245cad4ac520b337dee40c9a583872b6)
* x86: Expand the comment on when REP STOSB is used on memsetAdhemerval Zanella2024-04-041-1/+3
| | | | | Reviewed-by: H.J. Lu <hjl.tools@gmail.com> (cherry picked from commit 491e55beab7457ed310a4a47496f4a333c5d1032)
* x86: Do not prefer ERMS for memset on Zen3+Adhemerval Zanella2024-04-041-0/+5
| | | | | | | | | | For AMD Zen3+ architecture, the performance of the vectorized loop is slightly better than ERMS. Checked on x86_64-linux-gnu on Zen3. Reviewed-by: H.J. Lu <hjl.tools@gmail.com> (cherry picked from commit 272708884cb750f12f5c74a00e6620c19dc6d567)
* x86: Fix Zen3/Zen4 ERMS selection (BZ 30994)Adhemerval Zanella2024-04-041-20/+18
| | | | | | | | | | | | | | | | | | The REP MOVSB usage on memcpy/memmove does not show much performance improvement on Zen3/Zen4 cores compared to the vectorized loops. Also, as from BZ 30994, if the source is aligned and the destination is not the performance can be 20x slower. The performance difference is noticeable with small buffer sizes, closer to the lower bounds limits when memcpy/memmove starts to use ERMS. The performance of REP MOVSB is similar to vectorized instruction on the size limit (the L2 cache). Also, there is no drawback to multiple cores sharing the cache. Checked on x86_64-linux-gnu on Zen3. Reviewed-by: H.J. Lu <hjl.tools@gmail.com> (cherry picked from commit 0c0d39fe4aeb0f69b26e76337c5dfd5530d5d44e)
* Add tst-gnu2-tls2mod1 to test-internal-extrasAndreas Schwab2024-04-021-0/+2
| | | | | | | That allows sysdeps/x86_64/tst-gnu2-tls2mod1.S to use internal headers. Fixes: 717ebfa85c ("x86-64: Allocate state buffer space for RDI, RSI and RBX") (cherry picked from commit fd7ee2e6c5eb49e4a630a9978b4d668bff6354ee)
* elf: Enable TLS descriptor tests on aarch64Adhemerval Zanella2024-04-015-33/+40
| | | | | | | | | | | | | | The aarch64 uses 'trad' for traditional tls and 'desc' for tls descriptors, but unlike other targets it defaults to 'desc'. The gnutls2 configure check does not set aarch64 as an ABI that uses TLS descriptors, which then disable somes stests. Also rename the internal machinery fron gnu2 to tls descriptors. Checked on aarch64-linux-gnu. Reviewed-by: H.J. Lu <hjl.tools@gmail.com> (cherry picked from commit 3d53d18fc71c5d9ef4773b8bce04d54b80181926)
* arm: Update _dl_tlsdesc_dynamic to preserve caller-saved registers (BZ 31372)Adhemerval Zanella2024-04-0110-15/+250
| | | | | | | | | | | | | | | | | | | | | | | | ARM _dl_tlsdesc_dynamic slow path has two issues: * The ip/r12 is defined by AAPCS as a scratch register, and gcc is used to save the stack pointer before on some function calls. So it should also be saved/restored as well. It fixes the tst-gnu2-tls2. * None of the possible VFP registers are saved/restored. ARM has the additional complexity to have different VFP bank sizes (depending of VFP support by the chip). The tst-gnu2-tls2 test is extended to check for VFP registers, although only for hardfp builds. Different than setcontext, _dl_tlsdesc_dynamic does not have HWCAP_ARM_IWMMXT (I don't have a way to properly test it and it is almost a decade since newer hardware was released). With this patch there is no need to mark tst-gnu2-tls2 as XFAIL. Checked on arm-linux-gnueabihf. Reviewed-by: H.J. Lu <hjl.tools@gmail.com> (cherry picked from commit 64c7e344289ed085517c2227d8e3b06388242c13)
* Ignore undefined symbols for -mtls-dialect=gnu2Adhemerval Zanella2024-04-012-2/+2
| | | | | | | | So it does not fail for arm config that defaults to -mtp=soft (which issues a call to __aeabi_read_tp). Reviewed-by: H.J. Lu <hjl.tools@gmail.com> (cherry picked from commit 968b0ca9440040a2b31248a572891f0e55c1ab10)
* x86-64: Allocate state buffer space for RDI, RSI and RBXH.J. Lu2024-04-013-11/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _dl_tlsdesc_dynamic preserves RDI, RSI and RBX before realigning stack. After realigning stack, it saves RCX, RDX, R8, R9, R10 and R11. Define TLSDESC_CALL_REGISTER_SAVE_AREA to allocate space for RDI, RSI and RBX to avoid clobbering saved RDI, RSI and RBX values on stack by xsave to STATE_SAVE_OFFSET(%rsp). +==================+<- stack frame start aligned at 8 or 16 bytes | |<- RDI saved in the red zone | |<- RSI saved in the red zone | |<- RBX saved in the red zone | |<- paddings for stack realignment of 64 bytes |------------------|<- xsave buffer end aligned at 64 bytes | |<- | |<- | |<- |------------------|<- xsave buffer start at STATE_SAVE_OFFSET(%rsp) | |<- 8-byte padding for 64-byte alignment | |<- 8-byte padding for 64-byte alignment | |<- R11 | |<- R10 | |<- R9 | |<- R8 | |<- RDX | |<- RCX +==================+<- RSP aligned at 64 bytes Define TLSDESC_CALL_REGISTER_SAVE_AREA, the total register save area size for all integer registers by adding 24 to STATE_SAVE_OFFSET since RDI, RSI and RBX are saved onto stack without adjusting stack pointer first, using the red-zone. This fixes BZ #31501. Reviewed-by: Sunil K Pandey <skpgkp2@gmail.com> (cherry picked from commit 717ebfa85c8240d32d0d19d86a484c31c55c9617)
* x86-64: Update _dl_tlsdesc_dynamic to preserve AMX registersH.J. Lu2024-04-0114-6/+299
| | | | | | | | | | | | | | | | | | _dl_tlsdesc_dynamic should also preserve AMX registers which are caller-saved. Add X86_XSTATE_TILECFG_ID and X86_XSTATE_TILEDATA_ID to x86-64 TLSDESC_CALL_STATE_SAVE_MASK. Compute the AMX state size and save it in xsave_state_full_size which is only used by _dl_tlsdesc_dynamic_xsave and _dl_tlsdesc_dynamic_xsavec. This fixes the AMX part of BZ #31372. Tested on AMX processor. AMX test is enabled only for compilers with the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114098 GCC 14 and GCC 11/12/13 branches have the bug fix. Reviewed-by: Sunil K Pandey <skpgkp2@gmail.com> (cherry picked from commit 9b7091415af47082664717210ac49d51551456ab)
* x86: Update _dl_tlsdesc_dynamic to preserve caller-saved registersH.J. Lu2024-04-0124-213/+920
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compiler generates the following instruction sequence for GNU2 dynamic TLS access: leaq tls_var@TLSDESC(%rip), %rax call *tls_var@TLSCALL(%rax) or leal tls_var@TLSDESC(%ebx), %eax call *tls_var@TLSCALL(%eax) CALL instruction is transparent to compiler which assumes all registers, except for EFLAGS and RAX/EAX, are unchanged after CALL. When _dl_tlsdesc_dynamic is called, it calls __tls_get_addr on the slow path. __tls_get_addr is a normal function which doesn't preserve any caller-saved registers. _dl_tlsdesc_dynamic saved and restored integer caller-saved registers, but didn't preserve any other caller-saved registers. Add _dl_tlsdesc_dynamic IFUNC functions for FNSAVE, FXSAVE, XSAVE and XSAVEC to save and restore all caller-saved registers. This fixes BZ #31372. Add GLRO(dl_x86_64_runtime_resolve) with GLRO(dl_x86_tlsdesc_dynamic) to optimize elf_machine_runtime_setup. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit 0aac205a814a8511e98d02b91a8dc908f1c53cde)
* x86-64: Save APX registers in ld.so trampolineH.J. Lu2024-04-011-6/+46
| | | | | | | | | | | Add APX registers to STATE_SAVE_MASK so that APX registers are saved in ld.so trampoline. This fixes BZ #31371. Also update STATE_SAVE_OFFSET and STATE_SAVE_MASK for i386 which will be used by i386 _dl_tlsdesc_dynamic. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit dfb05f8e704edac70db38c4c8ee700769d91a413)
* LoongArch: Correct {__ieee754, _}_scalb -> {__ieee754, _}_scalbfcaiyinyu2024-03-221-1/+1
|
* powerpc: Placeholder and infrastructure/build support to add Power11 ↵Amrita H S2024-03-2015-5/+27
| | | | | | | | | | | | | related changes. The following three changes have been added to provide initial Power11 support. 1. Add the directories to hold Power11 files. 2. Add support to select Power11 libraries based on AT_PLATFORM. 3. Let submachine=power11 be set automatically. Reviewed-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Peter Bergner <bergner@linux.ibm.com> (cherry picked from commit 1ea051145612f199d8716ecdf78b084b00b5a727)
* powerpc: Add HWCAP3/HWCAP4 data to TCB for Power Architecture.Manjunath Matti2024-03-2012-19/+74
| | | | | | | | | | | | This patch adds a new feature for powerpc. In order to get faster access to the HWCAP3/HWCAP4 masks, similar to HWCAP/HWCAP2 (i.e. for implementing __builtin_cpu_supports() in GCC) without the overhead of reading them from the auxiliary vector, we now reserve space for them in the TCB. Suggested-by: Peter Bergner <bergner@linux.ibm.com> Reviewed-by: Peter Bergner <bergner@linux.ibm.com> (cherry picked from commit 3ab9b88e2ac91062b6d493fe32bd101a55006c6a)
* linux: Use rseq area unconditionally in sched_getcpu (bug 31479)Florian Weimer2024-03-181-8/+0
| | | | | | | | | | | | | | | | | | | | Originally, nptl/descr.h included <sys/rseq.h>, but we removed that in commit 2c6b4b272e6b4d07303af25709051c3e96288f2d ("nptl: Unconditionally use a 32-byte rseq area"). After that, it was not ensured that the RSEQ_SIG macro was defined during sched_getcpu.c compilation that provided a definition. This commit always checks the rseq area for CPU number information before using the other approaches. This adds an unnecessary (but well-predictable) branch on architectures which do not define RSEQ_SIG, but its cost is small compared to the system call. Most architectures that have vDSO acceleration for getcpu also have rseq support. Fixes: 2c6b4b272e6b4d07303af25709051c3e96288f2d Fixes: 1d350aa06091211863e41169729cee1bca39f72f Reviewed-by: Arjun Shankar <arjun@redhat.com> (cherry picked from commit 7a76f218677d149d8b7875b336722108239f7ee9)
* Use gcc __builtin_stdc_* builtins in stdbit.h if possibleJakub Jelinek2024-03-044-15/+856
| | | | | | | | | | | | | | | | | | The following patch uses the GCC 14 __builtin_stdc_* builtins in stdbit.h for the type-generic macros, so that when compiled with GCC 14 or later, it supports not just 8/16/32/64-bit unsigned integers, but also 128-bit (if target supports them) and unsigned _BitInt (any supported precision). And so that the macros don't expand arguments multiple times and can be evaluated in constant expressions. The new testcase is gcc's gcc/testsuite/gcc.dg/builtin-stdc-bit-1.c adjusted to test stdbit.h and the type-generic macros in there instead of the builtins and adjusted to use glibc test framework rather than gcc style tests with __builtin_abort (). Signed-off-by: Jakub Jelinek <jakub@redhat.com> Reviewed-by: Joseph Myers <josmyers@redhat.com> (cherry picked from commit da89496337b97e6a2aaf1e81d55cf998f6db1070)
* S390: Do not clobber r7 in clone [BZ #31402]Stefan Liebler2024-02-273-12/+63
| | | | | | | | | | | | | | Starting with commit e57d8fc97b90127de4ed3e3a9cdf663667580935 "S390: Always use svc 0" clone clobbers the call-saved register r7 in error case: function or stack is NULL. This patch restores the saved registers also in the error case. Furthermore the existing test misc/tst-clone is extended to check all error cases and that clone does not clobber registers in this error case. (cherry picked from commit 02782fd12849b6673cb5c2728cb750e8ec295aa3)
* math: Update mips64 ulpsXi Ruoyao2024-02-221-3/+4
| | | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> (cherry picked from commit e2a65ecc4b30a797df7dc6529f09b712aa256029)
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-05-09 16:21:51 +0000