This is the helper function, which uses struct __timespec64
to provide 64 bit absolute time to futex syscalls.
The aim of this function is to move convoluted pre-processor
macro code from sysdeps/nptl/lowlevellock-futex.h to C
function in futex-internal.c
The futex_abstimed_wait64 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).
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
It avoids regressions on possible future commands that might require
additional libc support. The downside is new commands added by newer
kernels will need further glibc support.
Checked on x86_64-linux-gnu and i686-linux-gnu (Linux v4.15 and v5.4).
Both commands are Linux extensions where the third argument is a
'struct msginfo' instead of 'struct msqid_ds' and its information
does not contain any time related fields (so there is no need to
extra conversion for __IPC_TIME64.
The regression testcase checks for Linux specifix SysV ipc message
control extension. For IPC_INFO/MSG_INFO it tries to match the values
against the tunable /proc values and for MSG_STAT/MSG_STAT_ANY it
check if the create message queue is within the global list returned
by the kernel.
Checked on x86_64-linux-gnu and on i686-linux-gnu (Linux v5.4 and on
Linux v4.15).
It avoids regressions on possible future commands that might require
additional libc support. The downside is new commands added by newer
kernels will need further glibc support.
Checked on x86_64-linux-gnu and i686-linux-gnu (Linux v4.15 and v5.4).
Handle SEM_STAT_ANY the same way as SEM_STAT so that the buffer argument
of SEM_STAT_ANY is properly passed to the kernel and back.
The regression testcase checks for Linux specifix SysV ipc message
control extension. For IPC_INFO/SEM_INFO it tries to match the values
against the tunable /proc values and for SEM_STAT/SEM_STAT_ANY it
check if the create message queue is within the global list returned
by the kernel.
Checked on x86_64-linux-gnu and on i686-linux-gnu (Linux v5.4 and on
Linux v4.15).
Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
There are several compiler implementations that allow large stack
allocations to jump over the guard page at the end of the stack and
corrupt memory beyond that. See CVE-2017-1000364.
Compilers can emit code to probe the stack such that the guard page
cannot be skipped, but on aarch64 the probe interval is 64K by default
instead of the minimum supported page size (4K).
This patch enforces at least 64K guard on aarch64 unless the guard
is disabled by setting its size to 0. For backward compatibility
reasons the increased guard is not reported, so it is only observable
by exhausting the address space or parsing /proc/self/maps on linux.
On other targets the patch has no effect. If the stack probe interval
is larger than a page size on a target then ARCH_MIN_GUARD_SIZE can
be defined to get large enough stack guard on libc allocated stacks.
The patch does not affect threads with user allocated stacks.
Fixes bug 26691.
Both powerpc64 and s390x provides semtimedop through __NR_ipc for
pre v5.1 kernel. Neither the y2038 support (7c437d3778) nor the
attempt to fix an issue for !__ASSUME_DIRECT_SYSVIPC_SYSCALLS
(aaa12e9ff0) took this in consideration.
This patch fixes it by issuing __NR_semtimedop_time64 iff it is
defined, otherwise __NR_semtimeop is issued if both
__ASSUME_DIRECT_SYSVIPC_SYSCALLS it set and __NR_semtimedop is
define, other __NR_ipc is used instead. To summarize:
1. For 32-bit architetures __NR_semtimedop_time64 is always
issued. The fallback is used only for !__ASSUME_TIME64_SYSCALLS
and it issues either __NR_ipc or __NR_semtimedop.
2. For 64-bit architecture with wire-up SysV syscall
(__ASSUME_DIRECT_SYSVIPC_SYSCALLS and __NR_semtimeop defined)
__NR_semtimeop is issued.
3. Otherwise __NR_ipc is used instead.
Checked on x86_64-linux-gnu, i686-linux-gnu (kernel 4.15 and 5.4),
powerpc64le (kernel 4.18), and s390x (kernel 4.12).
Reviewed-by: Matheus Castanho <msc@linux.ibm.com>
This alias macro shall be moved to the beginning of the futex-internal.h
to be easily reused by other functions, which would support 64 bit time.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It returns the string of the error constant, not its description (as
strerrordesc_np). To handle the Hurd error mapping, the ERR_MAP was
removed from errlist.h to errlist.c.
Also, the testcase test-strerr (added on 325081b9eb) was not added
on the check build neither it builds correctly. This patch also
changed it to decouple from errlist.h, the expected return values
are added explicitly for both both strerrorname_np and strerrordesc_np
directly.
Checked on x86_64-linux-gnu and i686-linux-gnu. I also run a make
check for i686-gnu.
The __x86_shared_non_temporal_threshold determines when memcpy on x86
uses non_temporal stores to avoid pushing other data out of the last
level cache.
This patch proposes to revert the calculation change made by H.J. Lu's
patch of June 2, 2017.
H.J. Lu's patch selected a threshold suitable for a single thread
getting maximum performance. It was tuned using the single threaded
large memcpy micro benchmark on an 8 core processor. The last change
changes the threshold from using 3/4 of one thread's share of the
cache to using 3/4 of the entire cache of a multi-threaded system
before switching to non-temporal stores. Multi-threaded systems with
more than a few threads are server-class and typically have many
active threads. If one thread consumes 3/4 of the available cache for
all threads, it will cause other active threads to have data removed
from the cache. Two examples show the range of the effect. John
McCalpin's widely parallel Stream benchmark, which runs in parallel
and fetches data sequentially, saw a 20% slowdown with this patch on
an internal system test of 128 threads. This regression was discovered
when comparing OL8 performance to OL7. An example that compares
normal stores to non-temporal stores may be found at
https://vgatherps.github.io/2018-09-02-nontemporal/. A simple test
shows performance loss of 400 to 500% due to a failure to use
nontemporal stores. These performance losses are most likely to occur
when the system load is heaviest and good performance is critical.
The tunable x86_non_temporal_threshold can be used to override the
default for the knowledgable user who really wants maximum cache
allocation to a single thread in a multi-threaded system.
The manual entry for the tunable has been expanded to provide
more information about its purpose.
modified: sysdeps/x86/cacheinfo.c
modified: manual/tunables.texi
The wire-up syscall __NR_recvmmsg_time64 (for 32-bit) or
__NR_recvmmsg (for 64-bit) 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_socketcall or __NR_recvmmsg
(32-bit time_t).
It does not handle the timestamps on ancillary data (SCM_TIMESTAMPING
records).
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
It uses __clock_nanosleep64 and adds the __nanosleep64 symbol.
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>
The generic version does not have time64 support and Linux default
uses utimensat. With hppa version gone, __ASSUME_UTIMES is not used
anymore.
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>
The syscall __NR_clock_getres_time64 (for 32-bit) or __NR_clock_getres
(for 64-bit) 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_rt_sigtimedwait (32-bit time_t).
Since the symbol does not use any type which might be affected by the
time_t, there is no need to add a 64-bit variant.
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>
The syscall __NR_sigtimedwait_time64 (for 32-bit) or __NR_sigtimedwait
(for 64-bit) 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_rt_sigtimedwait (32-bit time_t).
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
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_select/__NR__newselect or __NR_pselect6
(it should cover the microblaze case where older kernels do not
provide __NR_pselect6).
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>
Similar to 64-bit time __futex_abstimed_wait_cancellable64, it should
check for overflow and convert to 32-bit timespec iff timeout is not
NULL.
It fixes some regression on i686-linux-gnu running on a 4.15 kernel.
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>
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.
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>
This is similar to commit a26e2e9fea
"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>
commit 04bba1e5d8
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.
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.
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.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
- 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.
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.
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)
