about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* sparc: Fix la_symbind for bind-now (BZ 23734)Adhemerval Zanella2023-07-129-14/+66
| | | | | | | | | | | | | | | | | | | | | | | The sparc ABI has multiple cases on how to handle JMP_SLOT relocations, (sparc_fixup_plt/sparc64_fixup_plt). For BINDNOW, _dl_audit_symbind will be responsible to setup the final relocation value; while for lazy binding _dl_fixup/_dl_profile_fixup will call the audit callback and tail cail elf_machine_fixup_plt (which will call sparc64_fixup_plt). This patch fixes by issuing the SPARC specific routine on bindnow and forwarding the audit value to elf_machine_fixup_plt for lazy resolution. It fixes the la_symbind for bind-now tests on sparc64 and sparcv9: elf/tst-audit24a elf/tst-audit24b elf/tst-audit24c elf/tst-audit24d Checked on sparc64-linux-gnu and sparcv9-linux-gnu. Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> (cherry picked from commit dddc88587a7f48cbb361d9929ec23d790164eef8)
* nptl: Fix tst-cancel30 on sparc64Adhemerval Zanella2023-07-101-3/+1
| | | | | | | | As indicated by sparc kernel-features.h, even though sparc64 defines __NR_pause, it is not supported (ENOSYS). Always use ppoll or the 64 bit time_t variant instead. (cherry picked from commit 370da8a121c3ba9eeb2f13da15fc0f21f4136b25)
* elf: _dl_find_object may return 1 during early startup (bug 30515)Florian Weimer2023-07-073-1/+13
| | | | | | | | | | | | | Success is reported with a 0 return value, and failure is -1. Enhance the kitchen sink test elf/tst-audit28 to cover _dl_find_object as well. Fixes commit 5d28a8962dcb ("elf: Add _dl_find_object function") and bug 30515. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 1bcfe0f732066ae5336b252295591ebe7e51c301)
* realloc: Limit chunk reuse to only growing requests [BZ #30579]Siddhesh Poyarekar2023-07-061-8/+15
| | | | | | | | | | | | | | | | | | | | | | The trim_threshold is too aggressive a heuristic to decide if chunk reuse is OK for reallocated memory; for repeated small, shrinking allocations it leads to internal fragmentation and for repeated larger allocations that fragmentation may blow up even worse due to the dynamic nature of the threshold. Limit reuse only when it is within the alignment padding, which is 2 * size_t for heap allocations and a page size for mmapped allocations. There's the added wrinkle of THP, but this fix ignores it for now, pessimizing that case in favor of keeping fragmentation low. This resolves BZ #30579. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reported-by: Nicolas Dusart <nicolas@freedelity.be> Reported-by: Aurelien Jarno <aurelien@aurel32.net> Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Aurelien Jarno <aurelien@aurel32.net> (cherry picked from commit 2fb12bbd092b0c10f1f2083216e723d2406e21c4)
* hppa: xfail debug/tst-ssp-1 when have-ssp is yes (gcc-12 and later)John David Anglin2023-07-011-0/+4
|
* io: Fix F_GETLK, F_SETLK, and F_SETLKW for powerpc64Adhemerval Zanella2023-05-311-0/+6
| | | | | | | | | | | | | | | | | | | | Different than other 64 bit architectures, powerpc64 defines the LFS POSIX lock constants with values similar to 32 ABI, which are meant to be used with fcntl64 syscall. Since powerpc64 kABI does not have fcntl, the constants are adjusted with the FCNTL_ADJUST_CMD macro. The 4d0fe291aed3a476a changed the logic of generic constants LFS value are equal to the default values; which is now wrong for powerpc64. Fix the value by explicit define the previous glibc constants (powerpc64 does not need to use the 32 kABI value, but it simplifies the FCNTL_ADJUST_CMD which should be kept as compatibility). Checked on powerpc64-linux-gnu and powerpc-linux-gnu. (cherry picked from commit 5f828ff824e3b7cd133ef905b8ae25ab8a8f3d66)
* io: Fix record locking contants on 32 bit arch with 64 bit default time_t ↵Adhemerval Zanella2023-05-305-26/+135
| | | | | | | | | | | | | | | | | | | (BZ#30477) For architecture with default 64 bit time_t support, the kernel does not provide LFS and non-LFS values for F_GETLK, F_GETLK, and F_GETLK (the default value used for 64 bit architecture are used). This is might be considered an ABI break, but the currenct exported values is bogus anyway. The POSIX lockf is not affected since it is aliased to lockf64, which already uses the LFS values. Checked on i686-linux-gnu and the new tests on a riscv32. Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 4d0fe291aed3a476a3b59c4ecfae9d35ac0f15e8)
* Document BZ #20975 fixH.J. Lu2023-05-231-0/+1
|
* __check_pf: Add a cancellation cleanup handler [BZ #20975]H.J. Lu2023-05-232-0/+17
| | | | | | | | | | | | | | | | | | | | | | There are reports for hang in __check_pf: https://github.com/JoeDog/siege/issues/4 It is reproducible only under specific configurations: 1. Large number of cores (>= 64) and large number of threads (> 3X of the number of cores) with long lived socket connection. 2. Low power (frequency) mode. 3. Power management is enabled. While holding lock, __check_pf calls make_request which calls __sendto and __recvmsg. Since __sendto and __recvmsg are cancellation points, lock held by __check_pf won't be released and can cause deadlock when thread cancellation happens in __sendto or __recvmsg. Add a cancellation cleanup handler for __check_pf to unlock the lock when cancelled by another thread. This fixes BZ #20975 and the siege hang issue. (cherry picked from commit a443bd3fb233186038b8b483959ecb7978d1abea)
* Ignore MAP_VARIABLE in tst-mman-consts.pyJoseph Myers2023-05-171-2/+5
| | | | | | | | | | | | | Linux 6.2 removed the hppa compatibility MAP_VARIABLE define. That means that, whether or not we remove it in glibc, it needs to be ignored in tst-mman-consts.py (since this macro comparison infrastructure expects that new kernel header versions only add new macros, not remove old ones). Tested with build-many-glibcs.py for hppa-linux-gnu (Linux 6.2 headers). (cherry picked from commit 01e09ab0574758e0afff4333511866278ce7c84f)
* gmon: Revert addition of tunables to the manualFlorian Weimer2023-04-281-59/+0
| | | | | These tunables had to be removed over GLIBC_PRIVATE ABI stability concerns.
* gmon: Revert addition of tunables to preserve GLIBC_PRIVATE ABIFlorian Weimer2023-04-282-29/+1
| | | | | | | | Otherwise, processes are likely to crash during concurrent updates to a new glibc version on the stable release branch. The test gmon/tst-mcount-overflow depends on those tunables, so it has to be removed as well.
* gmon: fix memory corruption issues [BZ# 30101]Simon Kissane2023-04-284-8/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V2 of this patch fixes an issue in V1, where the state was changed to ON not OFF at end of _mcleanup. I hadn't noticed that (counterintuitively) ON=0 and OFF=3, hence zeroing the buffer turned it back on. So set the state to OFF after the memset. 1. Prevent double free, and reads from unallocated memory, when _mcleanup is (incorrectly) called two or more times in a row, without an intervening call to __monstartup; with this patch, the second and subsequent calls effectively become no-ops instead. While setting tos=NULL is minimal fix, safest action is to zero the whole gmonparam buffer. 2. Prevent memory leak when __monstartup is (incorrectly) called two or more times in a row, without an intervening call to _mcleanup; with this patch, the second and subsequent calls effectively become no-ops instead. 3. After _mcleanup, treat __moncontrol(1) as __moncontrol(0) instead. With zeroing of gmonparam buffer in _mcleanup, this stops the state incorrectly being changed to GMON_PROF_ON despite profiling actually being off. If we'd just done the minimal fix to _mcleanup of setting tos=NULL, there is risk of far worse memory corruption: kcount would point to deallocated memory, and the __profil syscall would make the kernel write profiling data into that memory, which could have since been reallocated to something unrelated. 4. Ensure __moncontrol(0) still turns off profiling even in error state. Otherwise, if mcount overflows and sets state to GMON_PROF_ERROR, when _mcleanup calls __moncontrol(0), the __profil syscall to disable profiling will not be invoked. _mcleanup will free the buffer, but the kernel will still be writing profiling data into it, potentially corrupted arbitrary memory. Also adds a test case for (1). Issues (2)-(4) are not feasible to test. Signed-off-by: Simon Kissane <skissane@gmail.com> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit bde121872001d8f3224eeafa5b7effb871c3fbca)
* gmon: improve mcount overflow handling [BZ# 27576]Simon Kissane2023-04-289-7/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When mcount overflows, no gmon.out file is generated, but no message is printed to the user, leaving the user with no idea why, and thinking maybe there is some bug - which is how BZ 27576 ended up being logged. Print a message to stderr in this case so the user knows what is going on. As a comment in sys/gmon.h acknowledges, the hardcoded MAXARCS value is too small for some large applications, including the test case in that BZ. Rather than increase it, add tunables to enable MINARCS and MAXARCS to be overridden at runtime (glibc.gmon.minarcs and glibc.gmon.maxarcs). So if a user gets the mcount overflow error, they can try increasing maxarcs (they might need to increase minarcs too if the heuristic is wrong in their case.) Note setting minarcs/maxarcs too large can cause monstartup to fail with an out of memory error. If you set them large enough, it can cause an integer overflow in calculating the buffer size. I haven't done anything to defend against that - it would not generally be a security vulnerability, since these tunables will be ignored in suid/sgid programs (due to the SXID_ERASE default), and if you can set GLIBC_TUNABLES in the environment of a process, you can take it over anyway (LD_PRELOAD, LD_LIBRARY_PATH, etc). I thought about modifying the code of monstartup to defend against integer overflows, but doing so is complicated, and I realise the existing code is susceptible to them even prior to this change (e.g. try passing a pathologically large highpc argument to monstartup), so I decided just to leave that possibility in-place. Add a test case which demonstrates mcount overflow and the tunables. Document the new tunables in the manual. Signed-off-by: Simon Kissane <skissane@gmail.com> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 31be941e4367c001b2009308839db5c67bf9dcbc)
* gmon: Fix allocated buffer overflow (bug 29444)Леонид Юрьев (Leonid Yuriev)2023-04-282-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `__monstartup()` allocates a buffer used to store all the data accumulated by the monitor. The size of this buffer depends on the size of the internal structures used and the address range for which the monitor is activated, as well as on the maximum density of call instructions and/or callable functions that could be potentially on a segment of executable code. In particular a hash table of arcs is placed at the end of this buffer. The size of this hash table is calculated in bytes as p->fromssize = p->textsize / HASHFRACTION; but actually should be p->fromssize = ROUNDUP(p->textsize / HASHFRACTION, sizeof(*p->froms)); This results in writing beyond the end of the allocated buffer when an added arc corresponds to a call near from the end of the monitored address range, since `_mcount()` check the incoming caller address for monitored range but not the intermediate result hash-like index that uses to write into the table. It should be noted that when the results are output to `gmon.out`, the table is read to the last element calculated from the allocated size in bytes, so the arcs stored outside the buffer boundary did not fall into `gprof` for analysis. Thus this "feature" help me to found this bug during working with https://sourceware.org/bugzilla/show_bug.cgi?id=29438 Just in case, I will explicitly note that the problem breaks the `make test t=gmon/tst-gmon-dso` added for Bug 29438. There, the arc of the `f3()` call disappears from the output, since in the DSO case, the call to `f3` is located close to the end of the monitored range. Signed-off-by: Леонид Юрьев (Leonid Yuriev) <leo@yuriev.ru> Another minor error seems a related typo in the calculation of `kcountsize`, but since kcounts are smaller than froms, this is actually to align the p->froms data. Co-authored-by: DJ Delorie <dj@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 801af9fafd4689337ebf27260aa115335a0cb2bc)
* posix: Fix system blocks SIGCHLD erroneously [BZ #30163]Adam Yi2023-04-288-3/+141
| | | | | | | | | | | | | | | | | | | | | | Fix bug that SIGCHLD is erroneously blocked forever in the following scenario: 1. Thread A calls system but hasn't returned yet 2. Thread B calls another system but returns SIGCHLD would be blocked forever in thread B after its system() returns, even after the system() in thread A returns. Although POSIX does not require, glibc system implementation aims to be thread and cancellation safe. This bug was introduced in 5fb7fc96350575c9adb1316833e48ca11553be49 when we moved reverting signal mask to happen when the last concurrently running system returns, despite that signal mask is per thread. This commit reverts this logic and adds a test. Signed-off-by: Adam Yi <ayi@janestreet.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 436a604b7dc741fc76b5a6704c6cd8bb178518e7)
* x86_64: Fix asm constraints in feraiseexcept (bug 30305)Florian Weimer2023-04-242-2/+3
| | | | | | | | | | The divss instruction clobbers its first argument, and the constraints need to reflect that. Fortunately, with GCC 12, generated code does not actually change, so there is no externally visible bug. Suggested-by: Jakub Jelinek <jakub@redhat.com> Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit 5d1ccdda7b0c625751661d50977f3dfbc73f8eae)
* gshadow: Matching sgetsgent, sgetsgent_r ERANGE handling (bug 30151)Florian Weimer2023-04-244-2/+75
| | | | | | | | | | | | | | Before this change, sgetsgent_r did not set errno to ERANGE, but sgetsgent only check errno, not the return value from sgetsgent_r. Consequently, sgetsgent did not detect any error, and reported success to the caller, without initializing the struct sgrp object whose address was returned. This commit changes sgetsgent_r to set errno as well. This avoids similar issues in applications which only change errno. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 969e9733c7d17edf1e239a73fa172f357561f440)
* stdio-common: tests: don't double-define _FORTIFY_SOURCESam James2023-04-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Exactly the same as 35bcb08eaa953c9b8bef6ab2486dc4361e1f26c0. If using -D_FORITFY_SOURCE=3 (in my case, I've patched GCC to add =3 instead of =2 (we've done =2 for years in Gentoo)), building glibc tests will fail on tst-bz11319-fortify2 like: ``` <command-line>: error: "_FORTIFY_SOURCE" redefined [-Werror] <built-in>: note: this is the location of the previous definition cc1: all warnings being treated as errors ``` It's just because we're always setting -D_FORTIFY_SOURCE=2 rather than unsetting it first. If F_S is already 2, it's harmless, but if it's another value (say, 1, or 3), the compiler will bawk. (I'm not aware of a reason this couldn't be tested with =3, but the toolchain support is limited for that (too new), and we want to run the tests everywhere possible.) As Siddhesh noted previously, we could implement some fallback logic to determine the maximal F_S value supported by the toolchain, which is a bit easier now that autoconf-archive has been updated for F_S=3 (https://github.com/autoconf-archive/autoconf-archive/pull/269), but let's revisit this if it continues to crop up. Signed-off-by: Sam James <sam@gentoo.org> Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit ecf8ae6704d5034fc2d5e29e5dc88dbca981581e)
* elf: Restore ldconfig libc6 implicit soname logic [BZ #30125]Joan Bruguera2023-02-208-23/+69
| | | | | | | | | | | | | | | | | | | | | | | While cleaning up old libc version support, the deprecated libc4 code was accidentally kept in `implicit_soname`, instead of the libc6 code. This causes additional symlinks to be created by `ldconfig` for libraries without a soname, e.g. a library `libsomething.123.456.789` without a soname will create a `libsomething.123` -> `libsomething.123.456.789` symlink. As the libc6 version of the `implicit_soname` code is a trivial `xstrdup`, just inline it and remove `implicit_soname` altogether. Some further simplification looks possible (e.g. the call to `create_links` looks like a no-op if `soname == NULL`, other than the verbose printfs), but logic is kept as-is for now. Fixes: BZ #30125 Fixes: 8ee878592c4a ("Assume only FLAG_ELF_LIBC6 suport") Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 1b0ea8c5d886fedabd611a569b5ec58a6f5153e6)
* stdlib: Undo post review change to 16adc58e73f3 [BZ #27749]Vitaly Buka2023-02-203-2/+81
| | | | | | | | | | | Post review removal of "goto restart" from https://sourceware.org/pipermail/libc-alpha/2021-April/125470.html introduced a bug when some atexit handers skipped. Signed-off-by: Vitaly Buka <vitalybuka@google.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit fd78cfa72ea2bab30fdb4e1e0672b34471426c05)
* elf: Smoke-test ldconfig -p against system /etc/ld.so.cacheFlorian Weimer2023-02-082-0/+83
| | | | | | | | | The test is sufficient to detect the ldconfig bug fixed in commit 9fe6f6363886aae6b2b210cae3ed1f5921299083 ("elf: Fix 64 time_t support for installed statically binaries"). Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 9fd63e35371b9939e9153907c6a753e6960b68ad)
* NEWS: Document CVE-2023-25139.Carlos O'Donell2023-02-071-0/+9
| | | | | Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 67c37737ed474d25fd4dc535dfd822c426e6b971)
* Account for grouping in printf width (bug 30068)Carlos O'Donell2023-02-073-5/+73
| | | | | | | | | | This is a partial fix for mishandling of grouping when formatting integers. It properly computes the width in the presence of grouping characters when the width is larger than the number of significant digits. The precision related issue is documented in bug 23432. Co-authored-by: Andreas Schwab <schwab@suse.de> (cherry picked from commit c980549cc6a1c03c23cc2fe3e7b0fe626a0364b0)
* Use 64-bit time_t interfaces in strftime and strptime (bug 30053)Andreas Schwab2023-02-076-2/+68
| | | | | | Both functions use time_t only internally, so the ABI is not affected. (cherry picked from commit 41349f6f67c83e7bafe49f985b56493d2c4c9c77)
* LoongArch: Add new relocation types.caiyinyu2023-02-031-0/+40
|
* cdefs: Limit definition of fortification macrosSiddhesh Poyarekar2023-02-021-2/+4
| | | | | | | | | | | | | Define the __glibc_fortify and other macros only when __FORTIFY_LEVEL > 0. This has the effect of not defining these macros on older C90 compilers that do not have support for variable length argument lists. Also trim off the trailing backslashes from the definition of __glibc_fortify and __glibc_fortify_n macros. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Florian Weimer <fweimer@redhat.com> (cherry picked from commit 2337e04e21ba6040926ec871e403533f77043c40)
* Create ChangeLog.old/ChangeLog.26. glibc-2.37Carlos O'Donell2023-01-311-0/+6942
|
* Prepare for glibc 2.37 release.Carlos O'Donell2023-01-312-3/+3
| | | | Update version.h, and include/features.h.
* x86: Fix strncat-avx2.S reading past length [BZ #30065]Noah Goldstein2023-01-312-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Occurs when `src` has no null-term. Two cases: 1) Zero-length check is doing: ``` test %rdx, %rdx jl L(zero_len) ``` which doesn't actually check zero (was at some point `decq` and the flag never got updated). The fix is just make the flag `jle` i.e: ``` test %rdx, %rdx jle L(zero_len) ``` 2) Length check in page-cross case checking if we should continue is doing: ``` cmpq %r8, %rdx jb L(page_cross_small) ``` which means we will continue searching for null-term if length ends at the end of a page and there was no null-term in `src`. The fix is to make the flag: ``` cmpq %r8, %rdx jbe L(page_cross_small) ```
* Update install.texi, and regenerate INSTALL.Carlos O'Donell2023-01-312-17/+17
|
* Update manual/contrib.texi.Carlos O'Donell2023-01-311-4/+12
| | | | | | | | | | | | Thank Yinyu Cai for their maintainership of the LoongArch port. Thank Vineet Gupta for their maintainership of the ARC port. Thank Tulio Magno Quites Machado Filho for their past maintainership of the PowerPC port. Thank Rajalakshmi Srinivasaraghavan for their current maintainership of the PowerPC port.
* Update NEWS file with bug fixes.Carlos O'Donell2023-01-311-6/+75
|
* Regenerate configure.Carlos O'Donell2023-01-312-3/+4
| | | | | | | Run using vanilla upstream autoconf 2.69. Minor whitespace change to sysdeps/loongarch/configure and sysdeps/mach/configure, and nothing else.
* Update all PO files in preparation for release.Carlos O'Donell2023-01-3137-10095/+8069
|
* doc: correct _FORTIFY_SOURCE doc in features.hfanquake2023-01-311-1/+2
|
* libio: Update number of written bytes in dprintf implementationFlorian Weimer2023-01-313-0/+47
| | | | | | | | | | | | The __printf_buffer_flush_dprintf function needs to record that the buffer has been written before reusing it. Without this accounting, dprintf always returns zero. Fixes commit 8ece45e4f586abd212d1c02d74d38ef681a45600 ("libio: Convert __vdprintf_internal to buffers"). Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Account for octal marker in %#o formatAndreas Schwab2023-01-303-0/+56
|
* Use binutils 2.40 branch in build-many-glibcs.pyJoseph Myers2023-01-271-1/+1
| | | | | | | This patch makes build-many-glibcs.py use binutils 2.40 branch. Tested with build-many-glibcs.py (host-libraries, compilers and glibcs builds).
* Use MPFR 4.2.0, MPC 1.3.1 in build-many-glibcs.pyJoseph Myers2023-01-271-2/+2
| | | | | | | | This patch makes build-many-glibcs.py use the new MPFR 4.2.0 and MPC 1.3.1 releases. Tested with build-many-glibcs.py (host-libraries, compilers and glibcs builds).
* stdio-common: Handle -1 buffer size in __sprintf_chk & co (bug 30039)Florian Weimer2023-01-254-10/+155
| | | | | | | | | | | | | | | This shows up as an assertion failure when sprintf is called with a specifier like "%.8g" and libquadmath is linked in: Fatal glibc error: printf_buffer_as_file.c:31 (__printf_buffer_as_file_commit): assertion failed: file->stream._IO_write_ptr <= file->next->write_end Fix this by detecting pointer wraparound in __vsprintf_internal and saturate the addition to the end of the address space instead. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Document '%F' format specifierPaul Pluzhnikov2023-01-251-11/+12
| | | | | | | | | | The '%F' format specifier was implemented in commit 6c46718f9f0 on 2000-08-23, but remains undocumented in the manual. https://stackoverflow.com/questions/75157669/format-specifier-f-missing-from-glibcs-documentation Fix that. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* sparc (64bit): Regenerate ulpsAndreas K. Hüttel2023-01-241-3/+4
| | | | | | | Linux catbus 5.15.69-gentoo #1 SMP Sat Sep 24 07:56:24 PDT 2022 sparc64 sun4v UltraSparc T5 (Niagara5) GNU/Linux gcc (Gentoo 11.3.1_p20221209 p3) 11.3.1 20221209 GNU ld (Gentoo 2.38 p4) 2.38 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* ia64: Regenerate ulpsAndreas K. Hüttel2023-01-241-2/+2
| | | | | | | Linux guppy 5.13.0-00002-gdecb01746d6c #368 SMP Sat Aug 14 20:10:13 UTC 2021 ia64 Dual-Core Intel(R) Itanium(R) Processor 9040 GenuineIntel GNU/Linux gcc (Gentoo 12.2.1_p20221231 p8) 12.2.1 20221231 GNU ld (Gentoo 2.40 p1) 2.40 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Update libc.pot for 2.37 release.Carlos O'Donell2023-01-231-306/+282
|
* x86: Cache computation for AMD architecture.Sajan Karumanchi2023-01-181-159/+45
| | | | | | | | All AMD architectures cache details will be computed based on __cpuid__ `0x8000_001D` and the reference to __cpuid__ `0x8000_0006` will be zeroed out for future architectures. Reviewed-by: Premachandra Mallappa <premachandra.mallappa@amd.com>
* manual: Fix typoMartin Joerg2023-01-181-1/+1
| | | | Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
* Add STATX_DIOALIGN from Linux 6.1 to bits/statx-generic.hJoseph Myers2023-01-171-0/+1
| | | | | | | Linux 6.1 adds a new STATX_DIOALIGN constant. Add it to glibc's bits/statx-generic.h. Tested for x86_64.
* Add IPPROTO_L2TP from Linux 6.1 to netinet/in.hJoseph Myers2023-01-171-0/+2
| | | | | | | | | Linux 6.1 adds a define IPPROTO_L2TP to its include/uapi/linux/in.h (not strictly a new constant, since it's moved from include/uapi/linux/l2tp.h). Add this constant to glibc's netinet/in.h. Tested for x86_64.
* AArch64: Improve strrchrWilco Dijkstra2023-01-171-25/+33
| | | | | | | | Use shrn for narrowing the mask which simplifies code and speeds up small strings. Unroll the first search loop to improve performance on large strings. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-18 21:24:29 +0000