about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* benchtests: Run _Float128 tests only on architectures that support itArjun Shankar2020-09-234-7/+11
| | | | | | | | | | __float128 is a non-standard name and is not available on some architectures (like aarch64 or s390x) even though they may support the standard _Float128 type. Other architectures (like armv7) don't support quad-precision floating-point operations at all. This commit replaces benchtests references to __float128 with _Float128 and runs the corresponding tests only on architectures that support it.
* powerpc: Protect dl_powerpc_cpu_features on INIT_ARCH() [BZ #26615]Raphael Moreira Zinsly2020-09-221-1/+1
| | | | | | | dl_powerpc_cpu_features also needs to be protected by __GLRO to check for the _rtld_global_ro realocation before accessing it. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
* x86: Harden printf against non-normal long double values (bug 26649)Florian Weimer2020-09-223-0/+64
| | | | | | | | | | | | | | | | | | | | | | | The behavior of isnan/__builtin_isnan on bit patterns that do not correspond to something that the CPU would produce from valid inputs is currently under-defined in the toolchain. (The GCC built-in and glibc disagree.) The isnan check in PRINTF_FP_FETCH in stdio-common/printf_fp.c assumes the GCC behavior that returns true for non-normal numbers which are not specified as NaN. (The glibc implementation returns false for such numbers.) At present, passing non-normal numbers to __mpn_extract_long_double causes this function to produce irregularly shaped multi-precision integers, triggering undefined behavior in __printf_fp_l. With GCC 10 and glibc 2.32, this behavior is not visible because __builtin_isnan is used, which avoids calling __mpn_extract_long_double in this case. This commit updates the implementation of __mpn_extract_long_double so that regularly shaped multi-precision integers are produced in this case, avoiding undefined behavior in __printf_fp_l.
* x86: Use one ldbl2mpn.c file for both i386 and x86_64Florian Weimer2020-09-223-2/+1
|
* Define __THROW to noexcept for C++11 and laterJonathan Wakely2020-09-221-4/+8
| | | | | | | | | | | | | The __THROW macro and friends expand to "throw ()" for C++ code, but that syntax is deprecated in C++11 and no longer supported at all since C++20. In order for glibc headers to be compatible with C++20, "noexcept" should be used instead. This patch uses "noexcept (true)" rather than just "noexcept", which is semantically equivalent, but avoids any possibility of parsing ambiguities if the next preprocessor token happens to be an opening parenthesis. This is probably unnecessary, but it seems safer to be cautious.
* Update mallinfo2 ABI, and testDJ Delorie2020-09-1738-2/+128
| | | | | | | This patch adds the ABI-related bits to reflect the new mallinfo2 function, and adds a test case to verify basic functionality. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Allow memset local PLT reference for RISC-V.Alistair Francis2020-09-171-0/+1
| | | | | | | | | | | | | | | | This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733 "Allow memset local PLT reference for powerpc soft-float.". GCC 10.1 results in the localplt test failing for RISC-V. From the original commit for power-pc: Since memset is documented as a function GCC may always implicitly generate calls to, it seems reasonable to allow that local PLT reference (just like those for libgcc functions that GCC implicitly generates calls to and that are also exported from libc.so), which this patch does. Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
* powerpc: fix ifunc implementation list for POWER9 strlen and stpcpyRaphael Moreira Zinsly2020-09-171-2/+2
| | | | | __strlen_power9 and __stpcpy_power9 were added to their ifunc lists using the wrong function names.
* nscd: bump GC cycle during cache pruning (bug 26130)Andreas Schwab2020-09-172-2/+11
| | | | | | | | While nscd prunes a cache it becomes inconsistent temporarily, which is visible to clients if that cache is shared. Bump the GC cycle counter so that the clients notice the modification window. Uniformly use atomic_fetch_add to modify the GC cycle counter.
* x86: Use HAS_CPU_FEATURE with IBT and SHSTK [BZ #26625]H.J. Lu2020-09-173-6/+4
| | | | | | | | | | | | | | | | commit 04bba1e5d84b6fd8d3a3b006bc240cd5d241ee30 Author: H.J. Lu <hjl.tools@gmail.com> Date: Wed Aug 5 13:51:56 2020 -0700 x86: Set CPU usable feature bits conservatively [BZ #26552] Set CPU usable feature bits only for CPU features which are usable in user space and whose usability can be detected from user space, excluding features like FSGSBASE whose enable bit can only be checked in the kernel. no longer turns on the usable bits of IBT and SHSTK since we don't know if IBT and SHSTK are usable until much later. Use HAS_CPU_FEATURE to check if the processor supports IBT and SHSTK.
* <sys/platform/x86.h>: Add Intel Key Locker supportH.J. Lu2020-09-164-3/+51
| | | | | | | | | | | | | | | | | | | | | | | Add Intel Key Locker: https://software.intel.com/content/www/us/en/develop/download/intel-key-locker-specification.html support to <sys/platform/x86.h>. Intel Key Locker has 1. KL: AES Key Locker instructions. 2. WIDE_KL: AES wide Key Locker instructions. 3. AESKLE: AES Key Locker instructions are enabled by OS. Applications should use if (CPU_FEATURE_USABLE (KL)) and if (CPU_FEATURE_USABLE (WIDE_KL)) to check if AES Key Locker instructions and AES wide Key Locker instructions are usable.
* Fix handling of collating symbols in fnmatch (bug 26620)Andreas Schwab2020-09-163-3/+41
| | | | | | The variable idx contains the index into the extra array, whereas wextra points into the extra array at this index, containing the length of the following collating sequence in the wide character representation.
* pselect.c: Pass a pointer to SYSCALL_CANCEL [BZ #26606]H.J. Lu2020-09-151-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit a92f4e6299fe0e3cb6f77e79de00817aece501ce Author: Adhemerval Zanella <adhemerval.zanella@linaro.org> Date: Mon Jul 6 13:27:12 2020 -0300 linux: Add time64 pselect support changed pselect.c to r = SYSCALL_CANCEL (pselect6_time64, nfds, readfds, writefds, exceptfds, timeout, ((__syscall_ulong_t[]){ (uintptr_t) sigmask, __NSIG_BYTES })); which doesn't work with x32's ARGIFY and data passed to syscall isn't initialized with sigmask and __NSIG_BYTES. Change to __syscall_ulong_t data[2] = { (uintptr_t) sigmask, __NSIG_BYTES }; r = SYSCALL_CANCEL (pselect6_time64, nfds, readfds, writefds, exceptfds, timeout, data); fixes [BZ #26606].
* y2038: nptl: Convert sem_{clock|timed}wait to support 64 bit timeLukasz Majewski2020-09-145-14/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The sem_clockwait and sem_timedwait have been converted to support 64 bit time. This change reuses futex_abstimed_wait_cancelable64 function introduced earlier. The sem_{clock|timed}wait only accepts absolute time. Moreover, there is no need to check for NULL passed as *abstime pointer to the syscalls as both calls have exported symbols marked with __nonull attribute for abstime. For systems with __TIMESIZE != 64 && __WORDSIZE == 32: - Conversion from 32 bit time to 64 bit struct __timespec64 was necessary - Redirection to __sem_{clock|timed}wait64 will provide support for 64 bit time Build tests: ./src/scripts/build-many-glibcs.py glibcs Run-time tests: - Run specific tests on ARM/x86 32bit systems (qemu): https://github.com/lmajewski/meta-y2038 and run tests: https://github.com/lmajewski/y2038-tests/commits/master Above tests were performed with Y2038 redirection applied as well as without to test the proper usage of both __sem_{clock|timed}wait64 and __sem_{clock|timed}wait. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* hurd: Add __x86_get_cpu_features to ld.abilistH.J. Lu2020-09-131-0/+1
| | | | Add __x86_get_cpu_features to ld.abilist for <sys/platform/x86.h>.
* x86: Install <sys/platform/x86.h> [BZ #26124]H.J. Lu2020-09-1118-247/+1176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Install <sys/platform/x86.h> so that programmers can do #if __has_include(<sys/platform/x86.h>) #include <sys/platform/x86.h> #endif ... if (CPU_FEATURE_USABLE (SSE2)) ... if (CPU_FEATURE_USABLE (AVX2)) ... <sys/platform/x86.h> exports only: enum { COMMON_CPUID_INDEX_1 = 0, COMMON_CPUID_INDEX_7, COMMON_CPUID_INDEX_80000001, COMMON_CPUID_INDEX_D_ECX_1, COMMON_CPUID_INDEX_80000007, COMMON_CPUID_INDEX_80000008, COMMON_CPUID_INDEX_7_ECX_1, /* Keep the following line at the end. */ COMMON_CPUID_INDEX_MAX }; struct cpuid_features { struct cpuid_registers cpuid; struct cpuid_registers usable; }; struct cpu_features { struct cpu_features_basic basic; struct cpuid_features features[COMMON_CPUID_INDEX_MAX]; }; /* Get a pointer to the CPU features structure. */ extern const struct cpu_features *__x86_get_cpu_features (unsigned int max) __attribute__ ((const)); Since all feature checks are done through macros, programs compiled with a newer <sys/platform/x86.h> are compatible with the older glibc binaries as long as the layout of struct cpu_features is identical. The features array can be expanded with backward binary compatibility for both .o and .so files. When COMMON_CPUID_INDEX_MAX is increased to support new processor features, __x86_get_cpu_features in the older glibc binaries returns NULL and HAS_CPU_FEATURE/CPU_FEATURE_USABLE return false on the new processor feature. No new symbol version is neeeded. Both CPU_FEATURE_USABLE and HAS_CPU_FEATURE are provided. HAS_CPU_FEATURE can be used to identify processor features. Note: Although GCC has __builtin_cpu_supports, it only supports a subset of <sys/platform/x86.h> and it is equivalent to CPU_FEATURE_USABLE. It doesn't support HAS_CPU_FEATURE.
* linux: Add time64 pselect supportAdhemerval Zanella2020-09-115-35/+115
| | | | | | | | | | | | | | | The syscall __NR_pselect6_time64 (32-bit) or __NR_pselect6 (64-bit) is used as default. For architectures with __ASSUME_TIME64_SYSCALLS the 32-bit fallback uses __NR_pselec6. To accomodate microblaze missing pselect6 support on kernel older than 3.15 the fallback is moved to its own function to the microblaze specific implementation can override it. Checked on x86_64-linux-gnu and i686-linux-gnu (on 5.4 and on 4.15 kernel). Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
* linux: Add time64 semtimedop supportAdhemerval Zanella2020-09-112-8/+55
| | | | | | | | | | | | Either the __NR_semtimedop_time64 (for 32-bit) or the __NR_semtimedop (for 64-bit) syscall is used as default. The 32-bit fallback is used iff __ASSUME_TIME64_SYSCALLS is not defined, which assumes the kernel ABI provides either __NR_ipc or __NR_semtimeop (for 32-bit time_t). Checked on x86_64-linux-gnu and i686-linux-gnu (on 5.4 and on 4.15 kernel). Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
* linux: Add ppoll time64 optimizationAdhemerval Zanella2020-09-111-5/+13
| | | | | | | | | | It avoid continuing issue the __NR_ppoll_time64 syscall once the kernel advertise it does not support it. Checked on x86_64-linux-gnu and i686-linux-gnu (on 5.4 and on 4.15 kernel). Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
* linux: Simplify clock_getresAdhemerval Zanella2020-09-111-23/+15
| | | | | | | | | | | | | With arch-syscall.h it can now assumes the existance of either __NR_clock_getres or __NR_clock_getres_time64. The 32-bit time_t support is now only build for !__ASSUME_TIME64_SYSCALLS. It also uses the time64-support functions to simplify it further. Checked on x86_64-linux-gnu and i686-linux-gnu (on 5.4 and on 4.15 kernel). Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
* Update sparc libm-test-ulpsAdhemerval Zanella2020-09-111-1/+1
|
* Remove internal usage of extensible stat functionsAdhemerval Zanella2020-09-1156-114/+109
| | | | | | | | | | | | It replaces the internal usage of __{f,l}xstat{at}{64} with the __{f,l}stat{at}{64}. It should not change the generate code since sys/stat.h explicit defines redirections to internal calls back to xstat* symbols. Checked with a build for all affected ABIs. I also check on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Linux: Consolidate xmknodAdhemerval Zanella2020-09-112-59/+3
| | | | | | | | | The __NR_mknodat syscall is supported on all kernels, so the generic implementation is used as default. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* linux: Consolidate fxstatat{64}Adhemerval Zanella2020-09-1123-301/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LFS support is implemented on fxstat64.c, instead of fxstat.c for 64-bit architectures. The fxstatat.c implements the non-LFS and it is a no-op for !XSTAT_IS_XSTAT64. The generic non-LFS implementation handles two cases: 1. New kABIs which uses generic pre 64-bit time Linux ABI (csky and nios): it issues __NR_fstatat64 plus handle the overflow on st_ino, st_size, or st_blocks. It only handles _STAT_VER_KERNEL. 2. Old kABIs with old non-LFS support (arm, i386, hppa, m68k, mips32, microblaze, s390, sh, powerpc, and sparc32). it issues __NR_fstatat64 and convert to non-LFS stat struct based on the version. Also non-LFS mips64 is an outlier and it has its own implementation since _STAT_VER_LINUX requires a different conversion function (it uses the kernel_stat as the sysissues argument since its exported ABI is different than the kernel one for both non-LFS and LFS implementation). The generic LFS implementation handles multiple cases: 1. XSTAT_IS_XSTAT64 being 1: 1.1. 64-bit kABI (aarch64, ia64, powerpc64*, s390x, riscv64, and x86_64): it issues __NR_newfstatat for _STAT_VER_KERNEL or _STAT_VER_LINUX. 1.2. 64-bit kABI outlier (sparc64): it issuess fstatat64 with a temporary stat64 and convert to output stat64 based on the input version (and using a sparc64 specific __xstat32_conv). 1.3. New 32-bit kABIs with only 64-bit time_t support (arc and riscv32): it issues __NR_statx and covert to struct stat64. 2. Old ABIs with XSTAT_IS_XSTAT64 being 0 (arm, csky, i386, hppa, m68k, microblaze, mips32, nios2, sh, powerpc32, and sparc32): it issues __NR_fstat64. Also, two special cases requires specific implementations: 1. alpha: it uses the __NR_fstatat64 syscall instead. 2. mips64: as for non-LFS implementation its ABIs differ from glibc exported one, which requires an specific conversion function to handle the kernel_stat. Checked with a build for all affected ABIs. I also checked on x86_64, i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and s390x. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* linux: Consolidate fxstat{64}Adhemerval Zanella2020-09-1118-268/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LFS support is implemented on fxstat64.c, instead of fxstat.c for 64-bit architectures. The fxstat.c implements the non-LFS and it is a no-op for !XSTAT_IS_XSTAT64. The generic non-LFS implementation handles two cases: 1. New kABIs which uses generic pre 64-bit time Linux ABI (csky and nios): it issuess __NR_fstat64 plus handle the overflow on st_ino, st_size, or st_blocks. It only handles _STAT_VER_KERNEL. 2. Old KABIs with old non-LFS support (arm, i386, hppa, m68k, microblaze, s390, sh, powerpc, and sparc32). For _STAT_VER_KERNEL it issues __NR_fstat, otherwise it calls __NR_fstat64 and convert to non-LFS stat struct and handle possible overflows on st_ino, st_size, or st_blocks. Also non-LFS mips is an outlier and it has its own implementation since _STAT_VER_LINUX requires a different conversion function (it uses the kernel_stat as the sysissues argument since its exported ABI is different than the kernel one for both non-LFS and LFS implementation). The generic LFS implementation handles multiple cases: 1. XSTAT_IS_XSTAT64 being 1: 1.1. 64-bit kABI (aarch64, ia64, powerpc64*, s390x, riscv64, and x86_64): it issuess __NR_fstat for _STAT_VER_KERNEL or _STAT_VER_LINUX. 1.2. Old 64-bit kABI with defines __NR_fstat64 instead of __NR_fstat (sparc64): it issues __NR_fstat for _STAT_VER_KERNEL or __NR_fstat64 and convert to struct stat64. 1.3. New 32-bit kABIs with only 64-bit time_t support (arc and riscv32): it issuess __NR_statx and covert to struct stat64. 2. Old ABIs with XSTAT_IS_XSTAT64 being 0 (arm, csky, i386, hppa, m68k, microblaze, mips32, nios2, sh, powerpc32, and sparc32): it issues __NR_fstat64. Also, two special cases requires specific implementations: 1. alpha: it requires to handle _STAT_VER_KERNEL64 to issues __NR_fstat64 and use the kernel_stat with __NR_fstat otherwise. 2. mips64: as for non-LFS implementation its ABIs differ from glibc exported one, which requires an specific conversion function to handle the kernel_stat. Checked with a build for all affected ABIs. I also checked on x86_64, i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and s390x. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* linux: Consolidate lxstat{64}Adhemerval Zanella2020-09-1119-345/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LFS support is implemented on lxstat64.c, instead of lxstat.c for 64-bit architectures. The xstat.c implements the non-LFS and it is a no-op for !XSTAT_IS_XSTAT64. The generic non-LFS implementation handles two cases: 1. New kABIs which uses generic pre 64-bit time Linux ABI (csky and nios): it issues __NR_fstat64 with AT_SYMLINK_NOFOLLOW plus handles the possible overflow off st_ino, st_size, or st_blocks. It only handles _STAT_VER_KERNEL. 2. Old KABIs with old non-LFS support (arm, i386, hppa, m68k, microblaze, s390, sh, powerpc, and sparc32). For _STAT_VER_KERNEL it issues __NR_lstat, otherwise it isseus __NR_lstat64 and convert to non-LFS stat struct and handle possible overflows on st_ino, st_size, or st_blocks. Also non-LFS mips is an outlier and it has its own implementation since _STAT_VER_LINUX requires a different conversion function (it uses the kernel_stat as the syscall argument since its exported ABI is different than the kernel one for both non-LFS and LFS implementation). The generic LFS implementation handles multiple cases: 1. XSTAT_IS_XSTAT64 being 1: 1.1. Old 64-bit kABI (ia64, powerpc64*, s390x, sparc64, x86_64): it issues __NR_lstat for _STAT_VER_KERNEL or _STAT_VER_LINUX. 1.2. Old 64-bit kABI with defines __NR_lstat64 instead of __NR_lstat (sparc64): it issues __NR_lstat for _STAT_VER_KERNEL or __NR_lstat64 and convert to struct stat64. 1.3. New kABIs which uses generic 64-bit Linux ABI (aarch64 and riscv64): it issues __NR_newfstatat with AT_SYMLINK_NOFOLLOW and only for _STAT_VER_KERNEL. 1.4. New 32-bit kABIs with only 64-bit time_t support (arc and riscv32): it issues __NR_statx and covert to struct stat64. 2. Old ABIs with XSTAT_IS_XSTAT64 being 0: 2.1. New kABIs which uses generic pre 64-bit time Linux ABI (csky and nios2): it issues __NR_fstatat64 for _STAT_VER_KERNEL. 2.2. Old kABIs with old non-LFS support (arm, i386, hppa, m68k, microblaze, s390, sh, mips32, powerpc32, and sparc32): it issues __NR_lstat64. Also, two special cases requires specific LFS implementations: 1. alpha: it requires to handle _STAT_VER_KERNEL64 to issue __NR_lstat64 and use the kernel_stat with __NR_lstat otherwise. 2. mips64: as for non-LFS implementation its ABIs differ from glibc exported one, which requires a specific conversion function to handle the kernel_stat. Checked with a build for all affected ABIs. I also checked on x86_64, i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and s390x. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* linux: Consolidate xstat{64}Adhemerval Zanella2020-09-1120-332/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LFS support is implemented on xstat64.c, instead of xstat.c for 64-bit architectures. The xstat.c implements the non-LFS it is no-op for !XSTAT_IS_XSTAT64. The generic non-LFS implementation handle two cases: 1. New kABIs which uses generic pre 64-bit time Linux ABI (csky and nios): it issues __NR_fstat64 plus handle the overflow on st_ino, st_size, or st_blocks. It only handles _STAT_VER_KERNEL. 2. Old KABIs with old non-LFS support (arm, i386, hppa, m68k, microblaze, s390, sh, powerpc, and sparc32). For _STAT_VER_KERNEL it issues __NR_stat, otherwise it issues __NR_stat64 and convert to non-LFS stat struct handling possible overflows on st_ino, st_size, or st_blocks. Also the non-LFS mips is an outlier and it has its own implementation since _STAT_VER_LINUX requires a different conversion function (it uses the kernel_stat as the syscall argument since its exported ABI is different than the kernel one for both non-LFS and LFS implementation). The generic LFS implementation handles multiple cases: 1. XSTAT_IS_XSTAT64 being 1: 1.1. Old 64-bit kABI (ia64, powerpc64*, s390x, x86_64): it issues __NR_stat for _STAT_VER_KERNEL or _STAT_VER_LINUX. 1.2. Old 64-bit kABI with defines __NR_stat64 instead of __NR_stat (sparc64): it issues __NR_stat for _STAT_VER_KERNEL or __NR_stat64 and convert to struct stat64. 1.3. New kABIs which uses generic 64-bit Linux ABI (aarch64 and riscv64): it issues __NR_newfstatat and only for _STAT_VER_KERNEL. 1.4. New 32-bit kABIs with only 64-bit time_t support (arc and riscv32): it issues __NR_statx and covert to struct stat64. 2. Old ABIs with XSTAT_IS_XSTAT64 being 0: 2.1. New kABIs which uses generic pre 64-bit time Linux ABI (csky and nios2): it issues __NR_fstatat64 for _STAT_VER_KERNEL. 2.2. Old kABIs with old non-LFS support (arm, i386, hppa, m68k, microblaze, s390, sh, mips32, powerpc32, and sparc32): it issues __NR_stat64. Also, two special cases requires specific LFS implementations: 1. alpha: it requires to handle _STAT_VER_KERNEL64 to call __NR_stat64 or use the kernel_stat with __NR_stat otherwise. 2. mips64: as for non-LFS implementation its ABIs differ from glibc exported one, which requires an specific conversion function to handle the kernel_stat. Checked with a build for all affected ABIs. I also checked on x86_64, i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and s390x. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* linux: Define STAT64_IS_KERNEL_STAT64Adhemerval Zanella2020-09-1113-0/+23
| | | | | | | | | | | It indicates that the glibc export stat64 is similar in size and layout of the kernel stat64 used on the syscall. It is not currently used on stat implementation, but the idea is to indicate whether to use the kernel_stat to issue on the syscall on the *stat*64 variant (more specifically on mips which its exported ABI does not match the kernel). Reviewed-by: Lukasz Majewski <lukma@denx.de>
* linux: Always define STAT_IS_KERNEL_STATAdhemerval Zanella2020-09-1114-7/+15
| | | | | | | | It allows to check for its value instead of its existence. Checked with a build for all affected ABIS. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Update powerpc libm-test-ulpsMatheus Castanho2020-09-101-3/+3
| | | | | | | | | | | | | Before this patch, the following tests were failing: ppc and ppc64: FAIL: math/test-ldouble-j0 ppc64le: FAIL: math/test-float128-j0 FAIL: math/test-float64x-j0 FAIL: math/test-ibm128-j0 FAIL: math/test-ldouble-j0
* benchtests: Add "workload" traces for sinf128Paul Zimmermann2020-09-102-1/+2008
| | | | | This patch adds workload traces for sinf128 in binary32. The trace is made of 1000 random numbers, generated with SageMath.
* benchtests: Add "workload" traces for sinfPaul Zimmermann2020-09-101-0/+2004
| | | | | This patch adds workload traces for sinf in binary32. The trace is made of 1000 random numbers, generated with SageMath.
* benchtests: Add "workload" traces for sinPaul Zimmermann2020-09-101-0/+2004
| | | | | This patch adds workload traces for sin in binary64. The trace is made of 1000 random numbers, generated with SageMath.
* benchtests: Add "workload" traces for powf128Paul Zimmermann2020-09-102-1/+1006
| | | | | This patch adds workload traces for pow in binary128. The trace is made of 1000 random numbers, generated with SageMath.
* benchtests: Add "workload" traces for powPaul Zimmermann2020-09-101-0/+1002
| | | | | This patch adds workload traces for pow in binary64. The trace is made of 1000 random numbers, generated with SageMath.
* benchtests: Add "workload" traces for expf128Paul Zimmermann2020-09-102-1/+1006
| | | | | This patch adds workload traces for exp in binary128. The trace is made of 1000 random numbers, generated with SageMath.
* benchtests: Add "workload" traces for expPaul Zimmermann2020-09-101-0/+1002
| | | | | This patch adds workload traces for exp in binary64. The trace is made of 1000 random numbers, generated with SageMath.
* nptl: futex: Provide correct indentation for part of ↵Lukasz Majewski2020-09-091-3/+3
| | | | | | | __futex_abstimed_wait_cancelable64 By mistake the if for calling __futex_abstimed_wait_cancellable32 was misaligned with the rest of the function body.
* Disable -Wstringop-overread for some string testsJoseph Myers2020-09-072-0/+11
| | | | | | | | | | Similarly to Maciej's changes to fix the build of rawmemchr in the presence of GCC 11's -Wstringop-overread, also disable that option in two string function tests that have similar warnings and other string function warnings already disabled. Tested with build-many-glibcs.py for aarch64-linux-gnu and arm-linux-gnueabi that it fixes building the glibc testsuite.
* string: Fix GCC 11 `-Werror=stringop-overread' errorMaciej W. Rozycki2020-09-071-0/+4
| | | | | | | | | | | | | | | Fix a compilation error: In function '__rawmemchr', inlined from '__rawmemchr' at rawmemchr.c:27:1: rawmemchr.c:36:12: error: 'memchr' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread] 36 | return memchr (s, c, (size_t)-1); | ^~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors ../o-iterator.mk:9: recipe for target '.../string/rawmemchr.o' failed introduced with GCC 11 commit d14c547abd48 ("Add -Wstringop-overread for reading past the end by string functions.").
* C11 threads: Fix inaccuracies in testsuiteCorinna Vinschen2020-09-073-3/+3
| | | | | | | | | | | | | | | | - tst-mtx-recursive.c: mtx_init fails to use mtx_plain. Per C11 specs, using mtx_recursive alone is not supported. This isn't catched because mtx_plain is defined as 0. - tst-thrd-sleep.c: thrd_sleep returns 0 on success, a negative value on failure. Testing against thrd_success is incorrect. - tst-tss-basic.c: tss_set is incorrectly checkd for a non-0 value. The test should test aginst C11 threads error codes. This isn't catched because thrd_success is defined as 0. Note that all three tests fail on FreeBSD, which defines all mutex type values, as well as all C11 threads error codes with non-0 values.
* elf.h: Add aarch64 bti/pac dynamic tag constantsMark Wielaard2020-09-071-0/+2
| | | | | | | | Constants double checked against binutils and the ELF for the Arm 64-bit Architecture (AArch64) Release 2020Q2 document. Only BTI PLT is used in glibc, there's no PAC PLT with glibc, and people are expected to use BIND_NOW.
* x86: Set CPU usable feature bits conservatively [BZ #26552]H.J. Lu2020-09-031-96/+47
| | | | | | Set CPU usable feature bits only for CPU features which are usable in user space and whose usability can be detected from user space, excluding features like FSGSBASE whose enable bit can only be checked in the kernel.
* Update i686 ulps.Patsy Griffin2020-09-021-3/+3
| | | | | | | | | | | | | Without this ULP patch these 3 tests fail on i686: FAIL: math/test-float128-j0 FAIL: math/test-float64x-j0 FAIL: math/test-ldouble-j0 CPU info: Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel Xeon Processor (Cascadelake)
* Use LFS readdir in generic POSIX getcwd [BZ# 22899]Adhemerval Zanella2020-09-022-4/+9
| | | | Checked on x86_64-linux-gnu and i686-linux-gnu.
* linux: Remove __ASSUME_ATFCTSAdhemerval Zanella2020-09-022-9/+0
| | | | | | The __have_atfcts is not used anywhere. Checked on x86_64-linux-gnu.
* Sync getcwd with gnulibAdhemerval Zanella2020-09-022-421/+376
| | | | | | | | | | This is the first of a series of patches to sync with Gnulib commit 615b43e1f9. This patch adopts most of the changes of Gnulib, except it retains GETCWD_RETURN_TYPE and does not always use a 64-bit internal API. These remaining discrepancies will be addressed in later patches in this series. Checked on x86_64-linux-gnu and i686-linux-gnu.
* x86-64: Fix FMA4 detection in ifunc [BZ #26534]Ondřej Hošek2020-09-021-1/+1
| | | | | | A typo in commit 107e6a3c2212ba7a3a4ec7cae8d82d73f7c95d0b causes the FMA4 code path to be taken on systems that support FMA, even if they do not support FMA4. Fix this to detect FMA4.
* y2038: nptl: Convert pthread_cond_{clock|timed}wait to support 64 bit timeLukasz Majewski2020-09-025-9/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pthread_cond_clockwait and pthread_cond_timedwait have been converted to support 64 bit time. This change introduces new futex_abstimed_wait_cancelable64 function in ./sysdeps/nptl/futex-helpers.c, which uses futex_time64 where possible and tries to replace low-level preprocessor macros from lowlevellock-futex.h The pthread_cond_{clock|timed}wait only accepts absolute time. Moreover, there is no need to check for NULL passed as *abstime pointer as __pthread_cond_wait_common() always passes non-NULL struct __timespec64 pointer to futex_abstimed_wait_cancellable64(). For systems with __TIMESIZE != 64 && __WORDSIZE == 32: - Conversions between 64 bit time to 32 bit are necessary - Redirection to __pthread_cond_{clock|timed}wait64 will provide support for 64 bit time The futex_abstimed_wait_cancelable64 function has been put into a separate file on the purpose - to avoid issues apparent on the m68k architecture related to small number of available registers (there is not enough registers to put all necessary arguments in them if the above function would be added to futex-internal.h with __always_inline attribute). In fact - new function - namely __futex_abstimed_wait_cancellable32 is used to reduce number of needed registers (as some in-register values are stored on the stack when function call is made). Build tests: ./src/scripts/build-many-glibcs.py glibcs Run-time tests: - Run specific tests on ARM/x86 32bit systems (qemu): https://github.com/lmajewski/meta-y2038 and run tests: https://github.com/lmajewski/y2038-tests/commits/master Above tests were performed with Y2038 redirection applied as well as without to test the proper usage of both __pthread_cond_{clock|timed}wait64 and __pthread_cond_{clock|timed}wait. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* malloc: Fix mallinfo deprecation declarationAdhemerval Zanella2020-08-313-2/+15
| | | | | | | | | | | | | | | | It fixes the build issue below introduced by e3960d1c57e57 (Add mallinfo2 function that support sizes >= 4GB). It moves the __MALLOC_DEPRECATED to the usual place for function attributes: In file included from ../include/malloc.h:3, from ../sysdeps/x86_64/multiarch/../../../test-skeleton.c:31, from ../sysdeps/x86_64/multiarch/test-multiarch.c:96: ../malloc/malloc.h:118:1: error: empty declaration [-Werror] 118 | __MALLOC_DEPRECATED; It also adds the required deprecated warning suppression on the tests. Checked on x86_64-linux-gnu.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-05 01:08:28 +0000