summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* Expose all MAP_ constants in <sys/mman.h> unconditionally (bug 29375)Andreas Schwab2022-10-1010-124/+90
| | | | | POSIX reserves the MAP_ prefix for <sys/mman.h>, so there is no need to conditionalize their definitions on feature test macros.
* LoongArch: Fix the condition to use PC-relative addressing in start.SXi Ruoyao2022-10-083-12/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A start.o compiled from start.S with -DPIC and no -DSHARED is used by both crt1.o and rcrt1.o. So the LoongArch static PIE patch unintentionally introduced PC-relative addressing for main and __libc_start_main into crt1.o. While the latest Binutils (trunk, which will be released as 2.40) supports the PC-relative relocs against an external function by creating a PLT entry, the 2.39 release branch doesn't (and won't) support this. An error is raised: "PLT stub does not represent and symbol not defined." So, we need the following changes: 1. Check if ld supports the PC-relative relocs against an external function. If it's not supported, we deem static PIE unsupported. 2. Change start.S. If static PIE is supported, use PC-relative addressing for main and __libc_start_main and rely on the linker to create PLT entries. Otherwise, restore the old behavior (using GOT to address these functions). An alternative would be adding a new "static-pie-start.S", and some custom logic into Makefile to build rcrt1.o with it. And, restore start.S to the state before static PIE change so crt1.o won't contain PC-relative relocs against external symbols. But I can't see any benefit of this alternative, so I'd just keep it simple. Tested by building glibc with the following configurations: 1. Binutils trunk + GCC trunk. Static PIE enabled. All tests passed. 2. Binutils 2.39 branch + GCC trunk. Static PIE disabled. Tests related to ifunc failed (it's a known issue). All other tests passed. 3. Binutils 2.39 branch + GCC 12 branch, cross compilation with build-many-glibcs.py from x86_64-linux-gnu. Static PIE disabled. Build succeeded.
* arm: Enable USE_ATOMIC_COMPILER_BUILTINS (BZ #24774)Adhemerval Zanella2022-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per other architectures. I have checked on a armv8 hardware with the following configurations: arm-linux-gnueabihf (gcc built with --with-float=hard --with-cpu=arm926ej-s) armv5-linux-gnueabihf (-march=armv5te -mfpu=vfpv3) armv7-linux-gnueabihf (-march=armv7-a -mfpu=vfpv3) armv7-thumb-linux-gnueabihf (-march=armv7-a -mfpu=vfpv3 -mthumb) armv7-neon-linux-gnueabihf (-march=armv7-a -mfpu=neon) armv7-neonhard-linux-gnueabihf (-march=armv7-a -mfpu=neon -mfloat-abi=hard) Without any regression. I haven't dig into the code, but since Linux atomic-machine.h handle pre-ARMv6 and ARMv6 I expect the compiler might have some small room to optimize. The code size also improves is most of the configurations: * master text data bss dec hex filename 1727801 9720 37928 1775449 1b1759 arm-linux-gnueabihf/libc.so 1691729 9720 37928 1739377 1a8a71 arm-linux-gnueabihf-armv7-disable-multi-arch/libc.so 1725509 9720 37928 1773157 1b0e65 armv5-linux-gnueabihf/libc.so 1700757 9720 37928 1748405 1aadb5 armv6-linux-gnueabihf/libc.so 1698973 9720 37928 1746621 1aa6bd armv6t2-linux-gnueabihf/libc.so 1695481 9752 37928 1743161 1a9939 armv7-linux-gnueabihf/libc.so 1692917 9744 37928 1740589 1a8f2d armv7-neonhard-linux-gnueabihf/libc.so 1692917 9744 37928 1740589 1a8f2d armv7-neon-linux-gnueabihf/libc.so 1225353 9752 37928 1273033 136cc9 armv7-thumb-linux-gnueabihf/libc.so * patched text data bss dec hex filename 1726805 9720 37928 1774453 1b1375 arm-linux-gnueabihf/libc.so 1689321 9720 37928 1736969 1a8109 arm-linux-gnueabihf-armv7-disable-multi-arch/libc.so 1724433 9720 37928 1772081 1b0a31 armv5-linux-gnueabihf/libc.so 1698301 9720 37928 1745949 1aa41d armv6-linux-gnueabihf/libc.so 1696525 9720 37928 1744173 1a9d2d armv6t2-linux-gnueabihf/libc.so 1693009 9752 37928 1740689 1a8f91 armv7-linux-gnueabihf/libc.so 1690493 9744 37928 1738165 1a85b5 armv7-neonhard-linux-gnueabihf/libc.so 1690493 9744 37928 1738165 1a85b5 armv7-neon-linux-gnueabihf/libc.so 1223837 9752 37928 1271517 1366dd armv7-thumb-linux-gnueabihf/libc.so The idea is eventually move all architectures to use compiler builtins. Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Aurelien Jarno <aurelien@aurel32.net>
* csu: Disable stack protector for static-reloc for static-pieAdhemerval Zanella2022-10-061-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For instance on x86_64 with gcc 12.1.1 andwith fstack-protector enabled the empty function still generates a stack protector code sequence: 0000000000000000 <_dl_relocate_static_pie>: 0: 48 83 ec 18 sub $0x18,%rsp 4: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax b: 00 00 d: 48 89 44 24 08 mov %rax,0x8(%rsp) 12: 31 c0 xor %eax,%eax 14: 48 8b 44 24 08 mov 0x8(%rsp),%rax 19: 64 48 2b 04 25 28 00 sub %fs:0x28,%rax 20: 00 00 22: 75 05 jne 29 <_dl_relocate_static_pie+0x29> 24: 48 83 c4 18 add $0x18,%rsp 28: c3 ret 29: e8 00 00 00 00 call 2e <_dl_relocate_static_pie+0x2e> And since the function is called prior thread pointer setup, it triggers a invalid memory access (this is shown with the failure of elf/tst-tls1-static-non-pie). Although it might characterizes as compiler issue or missed optimization, to be safe also disables stack protector on static-reloc object. Checked on x86_64-linux-gnu and sparc64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* NEWS: Fix grammarAndreas Schwab2022-10-061-1/+1
|
* elf: Simplify output of hwcap subdirectories in ld.so helpJavier Pello2022-10-061-36/+7
| | | | | | | | | The print_hwcap_1 machinery was useful for the legacy hwcaps subdirectories, but it is not worth the trouble now that they are gone. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* elf: Remove _dl_string_hwcapJavier Pello2022-10-0610-83/+0
| | | | | | | | Removal of legacy hwcaps support from the dynamic loader left no users of _dl_string_hwcap. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Add NEWS entry for legacy hwcaps removalJavier Pello2022-10-061-1/+4
| | | | | | | | Add a NEWS entry noting the removal of the legacy hwcaps search mechanism for shared objects. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* elf: Remove hwcap and bits_hwcap fields from struct cache_entryJavier Pello2022-10-061-22/+6
| | | | | | | | They were set to 0 on initialisation and never changed later after last commit. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* elf: Remove hwcap parameter from add_to_cache signatureJavier Pello2022-10-063-16/+5
| | | | | | | | Last commit made it so that the value passed for that parameter was always 0 at its only call site. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* elf: Remove legacy hwcaps support from ldconfigJavier Pello2022-10-061-145/+10
| | | | | | | Remove support for the legacy hwcaps subdirectories from ldconfig. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* elf: Remove legacy hwcaps support from the dynamic loaderJavier Pello2022-10-063-212/+10
| | | | | | | | Remove support for the legacy hwcaps subdirectories from the dynamic loader. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* x86_64: Remove platform directory library loading testJavier Pello2022-10-063-64/+0
| | | | | | | | | This was to test loading of shared libraries from platform subdirectories, but this functionality is going away in the following commits. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Update to Unicode 15.0.0 [BZ #29604]Mike FABIAN2022-10-0614-865/+1990
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unicode 15.0.0 Support: Character encoding, character type info, and transliteration tables are all updated to Unicode 15.0.0, using the generator scripts contributed by Mike FABIAN (Red Hat). Total added characters in newly generated CHARMAP: 4489 Total removed characters in newly generated WIDTH: 0 Total changed characters in newly generated WIDTH: 0 Total added characters in newly generated WIDTH: 4257 alpha: Added 4389 characters in new ctype which were not in old ctype combining: Added 42 characters in new ctype which were not in old ctype combining_level3: Added 34 characters in new ctype which were not in old ctype graph: Added 4489 characters in new ctype which were not in old ctype lower: Added 73 characters in new ctype which were not in old ctype print: Added 4489 characters in new ctype which were not in old ctype punct: Missing 5 characters of old ctype in new ctype punct: Missing: ఄ 0xc04 TELUGU SIGN COMBINING ANUSVARA ABOVE punct: Missing: ྂ 0xf82 TIBETAN SIGN NYI ZLA NAA DA punct: Missing: ྃ 0xf83 TIBETAN SIGN SNA LDAN punct: Missing: 𑂀 0x11080 KAITHI SIGN CANDRABINDU punct: Missing: 𑂁 0x11081 KAITHI SIGN ANUSVARA That’s OK, because these are now Alphabetic in DerivedCoreProperties.txt punct: Added 105 characters in new ctype which were not in old ctype Resolves: BZ #29604 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Update kernel version to 6.0 in header constant testsJoseph Myers2022-10-053-4/+4
| | | | | | | | | This patch updates the kernel version in the tests tst-mman-consts.py, tst-mount-consts.py and tst-pidfd-consts.py to 6.0. (There are no new constants covered by these tests in 6.0 that need any other header changes.) Tested with build-many-glibcs.py.
* x86: Fix -Os build (BZ #29576)Adhemerval Zanella Netto2022-10-051-0/+18
| | | | | | | | | | | The compiler might transform __stpcpy calls (which are routed to __builtin_stpcpy as an optimization) to strcpy and x86_64 strcpy multiarch implementation does not build any working symbol due ISA_SHOULD_BUILD not being evaluated for IS_IN(rtld). Checked on x86_64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* sunrpc: Suppress GCC -Os warning on user2netnameAdhemerval Zanella Netto2022-10-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | GCC with -Os warns that sprint might overflow: netname.c: In function ‘user2netname’: netname.c:51:28: error: ‘%s’ directive writing up to 255 bytes into a region of size between 239 and 249 [-Werror=format-overflow=] 51 | sprintf (netname, "%s.%d@%s", OPSYS, uid, dfltdom); | ^~ ~~~~~~~ netname.c:51:3: note: ‘sprintf’ output between 8 and 273 bytes into a destination of size 256 51 | sprintf (netname, "%s.%d@%s", OPSYS, uid, dfltdom); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors However the code does test prior the sprintf call that dfltdom plus the required extra space for OPSYS, uid, and extra character will not overflow and return 0 instead. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* rt: Initialize mq_send input on tst-mqueue{5,6}Adhemerval Zanella Netto2022-10-052-2/+2
| | | | | | | | | | | GCC with -Os warns that the mq_send input may be used uninitialized. Although for the tests the data content sent is not important, since both tests checks only if mq_notify was properly set, the warning is correct and data is indeed uninitialized. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* posix: Suppress -Os may be used uninitialized warnings on regexecAdhemerval Zanella Netto2022-10-051-0/+6
| | | | | | | | GCC with -Os issues may uninitialized warnings on regexec code. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* posix: Suppress -Os warnings on fnmatchAdhemerval Zanella Netto2022-10-051-0/+31
| | | | | | | | | | GCC with -Os issues some may uninitialized warnings on fnmatch code. All of the variables are already set when they are accessed on the loop prior. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* locale: prevent maybe-uninitialized errors with -Os [BZ #19444]Martin Jansa2022-10-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | Fixes following error when building with -Os: | In file included from strcoll_l.c:43: | strcoll_l.c: In function '__strcoll_l': | ../locale/weight.h:31:26: error: 'seq2.back_us' may be used uninitialized in this function [-Werror=maybe-uninitialized] | int_fast32_t i = table[*(*cpp)++]; | ^~~~~~~~~ | strcoll_l.c:304:18: note: 'seq2.back_us' was declared here | coll_seq seq1, seq2; | ^~~~ | In file included from strcoll_l.c:43: | ../locale/weight.h:31:26: error: 'seq1.back_us' may be used uninitialized in this function [-Werror=maybe-uninitialized] | int_fast32_t i = table[*(*cpp)++]; | ^~~~~~~~~ | strcoll_l.c:304:12: note: 'seq1.back_us' was declared here | coll_seq seq1, seq2; | ^~~~ Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Regenerate sysdeps/mach/hurd/bits/errno.hJoseph Myers2022-10-051-0/+1
| | | | | | | This addition to the list of source headers in sysdeps/mach/hurd/bits/errno.h appears in the source tree after build-many-glibcs.py runs, I'm guessing resulting from gnumach commit c566ad85a2d6728ebc8ec0f461a3b35df300e96e.
* Update syscall lists for Linux 6.0Joseph Myers2022-10-051-2/+2
| | | | | | | Linux 6.0 has no new syscalls. Update the version number in syscall-names.list to reflect that it is still current for 6.0. Tested with build-many-glibcs.py.
* nscd: Drop local address tuple variable [BZ #29607]Siddhesh Poyarekar2022-10-041-3/+2
| | | | | | | | | | | | | | | When a request needs to be resent (e.g. due to insufficient buffer space), the references to subsequent tuples in the local variable are stale and should not be used. This used to work by accident before, but since 1d495912a it no longer does. Instead of trying to reset it, just let gethostbyname4_r write into TUMPBUF6 for us, thus maintaining a consistent state at all times. This is now consistent with what is done in gaih_inet for getaddrinfo. Resolves: BZ #29607 Reported-by: Holger Hoffstätte <holger@applied-asynchrony.com> Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Use Linux 6.0 in build-many-glibcs.pyJoseph Myers2022-10-041-1/+1
| | | | | | | This patch makes build-many-glibcs.py use Linux 6.0. Tested with build-many-glibcs.py (host-libraries, compilers and glibcs builds).
* x86-64: Require BMI1/BMI2 for AVX2 strrchr and wcsrchr implementationsAurelien Jarno2022-10-033-3/+16
| | | | | | | | | | | The AVX2 strrchr and wcsrchr implementation uses the 'blsmsk' instruction which belongs to the BMI1 CPU feature and the 'shrx' instruction, which belongs to the BMI2 CPU feature. Fixes: df7e295d18ff ("x86: Optimize {str|wcs}rchr-avx2") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 and LZCNT for AVX2 memrchr implementationAurelien Jarno2022-10-033-2/+10
| | | | | | | | | | | The AVX2 memrchr implementation uses the 'shlxl' instruction, which belongs to the BMI2 CPU feature and uses the 'lzcnt' instruction, which belongs to the LZCNT CPU feature. Fixes: af5306a735eb ("x86: Optimize memrchr-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 for AVX2 (raw|w)memchr implementationsAurelien Jarno2022-10-031-3/+9
| | | | | | | | | | The AVX2 memchr, rawmemchr and wmemchr implementations use the 'bzhi' and 'sarx' instructions, which belongs to the BMI2 CPU feature. Fixes: acfd088a1963 ("x86: Optimize memchr-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 for AVX2 wcs(n)cmp implementationsAurelien Jarno2022-10-031-2/+6
| | | | | | | | | | | | | | The AVX2 wcs(n)cmp implementations use the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 for AVX2 strncmp implementationAurelien Jarno2022-10-032-4/+7
| | | | | | | | | | | | | | The AVX2 strncmp implementations uses the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 for AVX2 strcmp implementationAurelien Jarno2022-10-032-3/+5
| | | | | | | | | | | | | | The AVX2 strcmp implementation uses the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 for AVX2 str(n)casecmp implementationsAurelien Jarno2022-10-032-8/+21
| | | | | | | | | | | | | | The AVX2 str(n)casecmp implementations use the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86: include BMI1 and BMI2 in x86-64-v3 levelAurelien Jarno2022-10-031-0/+2
| | | | | | | | The "System V Application Binary Interface AMD64 Architecture Processor Supplement" mandates the BMI1 and BMI2 CPU features for the x86-64-v3 level. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86: Cleanup pthread_spin_{try}lock.SNoah Goldstein2022-10-032-12/+29
| | | | | | | | | | | | | Save a jmp on the lock path coming from an initial failure in pthread_spin_lock.S. This costs 4-bytes of code but since the function still fits in the same number of 16-byte blocks (default function alignment) it does not have affect on the total binary size of libc.so (unchanged after this commit). pthread_spin_trylock was using a CAS when a simple xchg works which is often more expensive. Full check passes on x86-64.
* Benchtests: Add bench for pthread_spin_{try}lock and mutex_trylockNoah Goldstein2022-10-036-12/+151
| | | | | Reuses infrastructure from previous pthread_mutex_lock benchmarks to test other performance sensitive functions.
* x86: Remove .tfloat usageAdhemerval Zanella2022-10-039-26/+47
| | | | | Some compiler does not support it (such as clang integrated assembler) neither gcc emits it.
* nptl: Convert tst-setuid2 to test-driverYu Chien Peter Lin2022-10-031-37/+15
| | | | | | | | Use <support/test-driver.c> and replace pthread calls to its xpthread equivalents. Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* support: Add xpthread_cond_signal wrapperYu Chien Peter Lin2022-10-033-0/+28
| | | | | Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* hppa: Fix initialization of dp register [BZ 29635]John David Anglin2022-10-011-5/+19
| | | | | | | | | | | | | After upgrading glibc to Debian 2.35-1, gdb faulted on startup and dropped core in a function call in the main application. This was caused by not initializing the global dp register for the main application early enough. Restore the code to initialize dp in _dl_start_user. It was removed when code was added to initialize dp in elf_machine_runtime_setup. Signed-off-by: John David Anglin <dave.anglin@bell.net>
* Fix iseqsig for _FloatN and _FloatNx in C++ with GCC 13Joseph Myers2022-09-302-1/+339
| | | | | | | | | | | | | | | | | | | | | | | | | | | With GCC 13, _FloatN and _FloatNx types, when they exist, are distinct types like they are in C with GCC 7 and later, rather than typedefs for types such as float, double or long double. This breaks the templated iseqsig implementation for C++ in <math.h>, when used with types that were previously implemented as aliases. Add the necessary definitions for _Float32, _Float64, _Float128 (when the same format as long double), _Float32x and _Float64x in this case, so that iseqsig can be used with such types in C++ with GCC 13 as it could with previous GCC versions. Also add tests for calling iseqsig in C++ with arguments of such types (more minimal than existing tests, so that they can work with older GCC versions and without relying on any C++ library support for the types or on hardcoding details of their formats). The LDBL_MANT_DIG != 106 conditionals on some tests are because the type-generic comparison macros have undefined behavior when neither argument has a type whose set of values is a subset of those for the type of the other argument, which applies when one argument is IBM long double and the other is an IEEE format wider than binary64. Tested with build-many-glibcs.py glibcs build for aarch64-linux-gnu i686-linux-gnu mips-linux-gnu mips64-linux-gnu-n32 powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu.
* malloc: Do not clobber errno on __getrandom_nocancel (BZ #29624)Adhemerval Zanella2022-09-303-4/+12
| | | | | | | | | | Use INTERNAL_SYSCALL_CALL instead of INLINE_SYSCALL_CALL. This requires emulate the semantic for hurd call (so __arc4random_buf uses the fallback). Checked on x86_64-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* stdlib: Fix __getrandom_nocancel type and arc4random usage (BZ #29638)Adhemerval Zanella2022-09-302-2/+2
| | | | | | | | | Using an unsigned type prevents the fallback to be used if kernel does not support getrandom syscall. Checked on x86_64-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* LoongArch: Add static PIE supportXi Ruoyao2022-09-303-3/+95
| | | | | | | If the compiler is new enough, enable static PIE support. In the static PIE version of _start (in rcrt1.o), use la.pcrel instead of la.got because in a static PIE we cannot use GOT entries until the dynamic relocations for GOT are resolved.
* Benchtest: Add additional benchmarks for strlen and strnlenNoah Goldstein2022-09-282-7/+81
| | | | | Current benchmarks are missing many cases in the mid-length range which is often the hottest size range.
* x86: Fix wcsnlen-avx2 page cross length comparison [BZ #29591]Noah Goldstein2022-09-282-34/+43
| | | | | | | | | | | Previous implementation was adjusting length (rsi) to match bytes (eax), but since there is no bound to length this can cause overflow. Fix is to just convert the byte-count (eax) to length by dividing by sizeof (wchar_t) before the comparison. Full check passes on x86-64 and build succeeds w/ and w/o multiarch.
* Update _FloatN header support for C++ in GCC 13Joseph Myers2022-09-286-35/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC 13 adds support for _FloatN and _FloatNx types in C++, so breaking the installed glibc headers that assume such support is not present. GCC mostly works around this with fixincludes, but that doesn't help for building glibc and its tests (glibc doesn't itself contain C++ code, but there's C++ code built for tests). Update glibc's bits/floatn-common.h and bits/floatn.h headers to handle the GCC 13 support directly. In general the changes match those made by fixincludes, though I think the ones in sysdeps/powerpc/bits/floatn.h, where the header tests __LDBL_MANT_DIG__ == 113 or uses #elif, wouldn't match the existing fixincludes patterns. Some places involving special C++ handling in relation to _FloatN support are not changed. There's no need to change the __HAVE_FLOATN_NOT_TYPEDEF definition (also in a form that wouldn't be matched by the fixincludes fixes) because it's only used in relation to macro definitions using features not supported for C++ (__builtin_types_compatible_p and _Generic). And there's no need to change the inline function overloads for issignaling, iszero and iscanonical in C++ because cases where types have the same format but are no longer compatible types are handled automatically by the C++ overload resolution rules. This patch also does not change the overload handling for iseqsig, and there I think changes *are* needed, beyond those in this patch or made by fixincludes. The way that overload is defined, via a template parameter to a structure type, requires overloads whenever the types are incompatible, even if they have the same format. So I think we need to add overloads with GCC 13 for every supported _FloatN and _FloatNx type, rather than just having one for _Float128 when it has a different ABI to long double as at present (but for older GCC, such overloads must not be defined for types that end up defined as typedefs for another type). Tested with build-many-glibcs.py: compilers build for aarch64-linux-gnu ia64-linux-gnu mips64-linux-gnu powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu; glibcs build for aarch64-linux-gnu ia64-linux-gnu i686-linux-gnu mips-linux-gnu mips64-linux-gnu-n32 powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu.
* hurd: Fix typoSamuel Thibault2022-09-281-1/+1
|
* get_nscd_addresses: Fix subscript typos [BZ #29605]Jörg Sonnenberger2022-09-281-3/+3
| | | | | | | | | Fix the subscript on air->family, which was accidentally set to COUNT when it should have remained as I. Resolves: BZ #29605 Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* hurd: Increase SOMAXCONN to 4096Samuel Thibault2022-09-271-1/+1
| | | | Notably fakeroot-tcp may introduce a lot of parallel connections.
* Use atomic_exchange_release/acquireWilco Dijkstra2022-09-2631-39/+39
| | | | | | | Rename atomic_exchange_rel/acq to use atomic_exchange_release/acquire since these map to the standard C11 atomic builtins. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-24 18:00:23 +0000