This conversion patch for supporting 64 bit time for futimesat only differs
from the work performed for futimes (when providing __futimes64) with passing
also the file name (and path) to utimensat.
All the design and conversion decisions are exactly the same as for futimens
conversion.
This conversion patch for supporting 64 bit time for lutimes mostly differs from
the work performed for futimes (when providing __futimes64) with adding the
AT_SYMLINK_NOFOLLOW flag to utimensat.
It also supports passing file name instead of file descriptor number, but this
is not relevant for utimensat used to implement it.
All the design and conversion decisions are exactly the same as for futimens
conversion.
This patch provides new __futimes64 explicit 64 bit function for setting file's
64 bit attributes for access and modification time (by specifying file
descriptor number).
Internally, the __utimensat64_helper function is used. This patch is necessary
for having architectures with __WORDSIZE == 32 Y2038 safe.
Moreover, a 32 bit version - __futimes has been refactored to internally use
__futimes64.
The __futimes is now supposed to be used on systems still supporting 32
bit time (__TIMESIZE != 64) - hence the necessary conversion of struct timeval
to 64 bit struct __timeval64.
The check if struct timevals' usec fields are in the range between 0 and 1000000
has been removed as Linux kernel performs it internally in the implementation
of utimensat (the conversion between struct __timeval64 and __timespec64 is not
relevant for this particular check).
Last but not least, checks for tvp{64} not being NULL have been preserved from
the original code as some legacy user space programs may rely on it.
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 __futimes64 and __futimes.
It seems that some gcc versions might generates a stack frame for the
sigreturn stub requires on sparc signal handling. For instance:
$ cat test.c
#define _GNU_SOURCE
#include <sys/syscall.h>
__attribute__ ((__optimize__ ("-fno-stack-protector")))
void
__sigreturn_stub (void)
{
__asm__ ("mov %0, %%g1\n\t"
"ta 0x10\n\t"
: /* no outputs */
: "i" (SYS_rt_sigreturn));
}
$ gcc -v
[...]
gcc version 9.2.1 20200224 (Debian 9.2.1-30)
$ gcc -O2 -m64 test.c -S -o -
[...]
__sigreturn_stub:
save %sp, -176, %sp
#APP
! 9 "t.c" 1
mov 101, %g1
ta 0x10
! 0 "" 2
#NO_APP
.size __sigreturn_stub, .-__sigreturn_stub
As indicated by kernel developers [1], the sigreturn stub can not change
the register window or the stack pointer since the kernel has setup the
restore frame at a precise location relative to the stack pointer when
the stub is invoked.
I tried to play with some compiler flags and even with _Noreturn and
__builtin_unreachable after the asm does not help (and Sparc does not
support naked functions).
To avoid similar issues, as the stack-protector support also have
stumbled, this patch moves the implementation of the sigreturn stubs to
assembly.
Checked on sparcv9-linux-gnu and sparc64-linux-gnu with gcc 9.2.1
and gcc 7.5.0.
[1] https://lkml.org/lkml/2016/5/27/465
The kernel might not clear the padding value for the ipc_perm mode
fields in compat mode (32 bit running on a 64 bit kernel). It was
fixed on v4.14 when the ipc compat code was refactored to move
(commits 553f770ef71b, 469391684626, c0ebccb6fa1e).
Although it is most likely a kernel issue, it was shown only due
BZ#18231 fix which made all the SysVIPC mode_t 32-bit regardless of
the kABI.
This patch fixes it by explicitly zeroing the upper bits for such
cases. The __ASSUME_SYSVIPC_BROKEN_MODE_T case already handles
it with the shift.
(The aarch64 ipc_priv.h is superflous since
__ASSUME_SYSVIPC_DEFAULT_IPC_64 is now defined as default).
Checked on i686-linux-gnu on 3.10 and on 4.15 kernel.
fstatat64 depends on inlining to produce the desired __fxstatat64
call, which does not happen with -Os, leading to a link failure
with an undefined reference to fstatat64. __fxstatat64 has a macro
definition in include/sys/stat.h and thus avoids the problem.
This patch replaces auto generated wrapper (as described in
sysdeps/unix/sysv/linux/syscalls.list) for utime with one which adds extra
support for setting file's access and modification 64 bit time on machines
with __TIMESIZE != 64.
Internally, the __utimensat_time64 helper function is used. This patch is
necessary for having architectures with __WORDSIZE == 32 && __TIMESIZE != 64
Y2038 safe.
Moreover, a 32 bit version - __utime has been refactored to internally use
__utime64.
The __utime is now supposed to be used on systems still supporting 32
bit time (__TIMESIZE != 64) - hence the necessary conversion between struct
utimbuf and struct __utimbuf64.
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 proper usage of both __utime64 and __utime.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch provides new __utimes64 explicit 64 bit function for setting file's
64 bit attributes for access and modification time.
Internally, the __utimensat64_helper function is used. This patch is necessary
for having architectures with __WORDSIZE == 32 Y2038 safe.
Moreover, a 32 bit version - __utimes has been refactored to internally use
__utimes64.
The __utimes is now supposed to be used on systems still supporting 32
bit time (__TIMESIZE != 64) - hence the necessary conversion of struct
timeval to 64 bit struct __timeval64.
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 proper usage of both __utimes64 and __utimes.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Due to the built-in tables, __NR_vfork is always defined, so the
fork-based fallback code is never used.
(It appears that the vfork system call was wired up when the port was
contributed to the kernel.)
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Due to the built-in tables, __NR_getdents64 is always defined,
although it may not be supported at run time.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
With the built-in tables __NR_preadv2 and __NR_pwritev2 are always
defined.
The kernel has never defined __NR_preadv64v2 and __NR_pwritev64v2
and is unlikely to do so, given that the preadv2 and pwritev2 system
calls themselves are 64-bit.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Due to the built-in tables, __NR_rt_sigqueueinfo is always defined.
sysdeps/pthread/time_routines.c is not updated because it is shared with
Hurd.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The names __NR_preadv64, __NR_pwritev64 appear to be a glibc invention.
With the built-in tables, __NR_preadv and __NR_pwritev are always defined.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Linux removed the last definitions of __NR_pread and __NR_pwrite
in commit 4ba66a9760722ccbb691b8f7116cad2f791cca7b, the removal
of the blackfin port. All architectures now define __NR_pread64 and
__NR_pwrite64 only.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Due to the built-in tables, __NR_mq_getsetattr, __NR_mq_notify,
__NR_mq_open, __NR_mq_timedreceive, __NR_mq_timedsend, __NR_mq_unlink
are always defined.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Writable, executable segments defeat security hardening. The
existing check for DT_TEXTREL does not catch this.
hppa and SPARC currently keep the PLT in an RWX load segment.
It is necessary to export __pthread_cond_init from libc because
the C11 condition variable needs it and is still left in libpthread.
This is part of the libpthread removal project:
<https://sourceware.org/ml/libc-alpha/2019-10/msg00080.html>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It is necessary to export __pthread_cond_destroy from libc because
the C11 condition variable needs it and is still left in libpthread.
This is part of the libpthread removal project:
<https://sourceware.org/ml/libc-alpha/2019-10/msg00080.html>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The behavior of the signal mask on threads created by timer_create
for SIGEV_THREAD timers are implementation-defined and glibc explicit
unblocks all signals before calling the user-defined function.
This behavior, although not incorrect standard-wise, opens a race if a
program using a blocked rt-signal plus sigwaitinfo (and without an
installed signal handler for the rt-signal) receives a signal while
executing the used-defined function for SIGEV_THREAD.
A better alternative discussed in bug report is to rather block all
signals (besides the internal ones not available to application
usage).
This patch fixes this issue by only unblocking SIGSETXID (used on
set*uid function) and SIGCANCEL (used for thread cancellation).
Checked on x86_64-linux-gnu and i686-linux-gnu.
From the GNU C Library manual, the pkey_set can receive a combination of
PKEY_DISABLE_WRITE and PKEY_DISABLE_ACCESS. However PKEY_DISABLE_ACCESS
is more restrictive than PKEY_DISABLE_WRITE and includes its behavior.
The test expects that after setting
(PKEY_DISABLE_WRITE|PKEY_DISABLE_ACCESS) pkey_get should return the
same. This may not be true as PKEY_DISABLE_ACCESS will succeed in
describing the state of the key in this case.
The pkey behavior during signal handling is different between x86 and
POWER. This change make the test compatible with both architectures.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
In the glibc the gettimeofday can use vDSO (on power and x86 the
USE_IFUNC_GETTIMEOFDAY is defined), gettimeofday syscall or 'default'
___gettimeofday() from ./time/gettime.c (as a fallback).
In this patch the last function (___gettimeofday) has been refactored and
moved to ./sysdeps/unix/sysv/linux/gettimeofday.c to be Linux specific.
The new __gettimeofday64 explicit 64 bit function for getting 64 bit time from
the kernel (by internally calling __clock_gettime64) has been introduced.
Moreover, a 32 bit version - __gettimeofday has been refactored to internally
use __gettimeofday64.
The __gettimeofday is now supposed to be used on systems still supporting 32
bit time (__TIMESIZE != 64) - hence the necessary check for time_t potential
overflow and conversion of struct __timeval64 to 32 bit struct timespec.
The iFUNC vDSO direct call optimization has been removed from both i686 and
powerpc32 (USE_IFUNC_GETTIMEOFDAY is not defined for those architectures
anymore). The Linux kernel does not provide a y2038 safe implementation of
gettimeofday neither it plans to provide it in the future, clock_gettime64
should be used instead. Keeping support for this optimization would require
to handle another build permutation (!__ASSUME_TIME64_SYSCALLS &&
USE_IFUNC_GETTIMEOFDAY) which adds more complexity and has limited use
(since the idea is to eventually have a y2038 safe glibc build).
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 proper usage of both __gettimeofday64 and __gettimeofday.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
[Including some commit message improvement]
It appears that the ability to change symbolic link modes through such
paths is unintended. On several file systems, the operation fails with
EOPNOTSUPP, even though the symbolic link permissions are updated.
The expected behavior is a failure to update the permissions, without
file system changes.
Reviewed-by: Matheus Castanho <msc@linux.ibm.com>
MIPS fallback code handle a frame where its FDE can not be obtained
(for instance a signal frame) by reading the kernel allocated signal frame
and adding '2' to the value of 'sc_pc' [1]. The added value is used to
recognize an end of an EH region on mips16 [2].
The fix adjust the obtained signal frame value and remove the libgcc added
value by checking if the previous frame is a signal frame one.
Checked with backtrace and tst-sigcontext-get_pc tests on mips-linux-gnu
and mips64-linux-gnu.
[1] libgcc/config/mips/linux-unwind.h from gcc code.
[2] gcc/config/mips/mips.h from gcc code. */
The new type struct fd_to_filename makes the allocation of the
backing storage explicit.
Hurd uses /dev/fd, not /proc/self/fd.
Co-Authored-By: Paul Eggert <eggert@cs.ucla.edu>
Exporting functions and relying on symbol interposition from libc.so
makes the choice of implementation dependent on DT_NEEDED order, which
is not what some compiler drivers expect.
This commit replaces one magic mechanism (symbol interposition) with
another one (preprocessor-/compiler-based redirection). This makes
the hand-over from the minimal malloc to the full malloc more
explicit.
Removing the ABI symbols is backwards-compatible because libc.so is
always in scope, and the dynamic loader will find the malloc-related
symbols there since commit f0b2132b35
("ld.so: Support moving versioned symbols between sonames
[BZ #24741]").
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
With all Linux ABIs using the expected Linux kABI to indicate
syscalls errors, the INTERNAL_SYSCALL_DECL is an empty declaration
on all ports.
This patch removes the 'err' argument on INTERNAL_SYSCALL* macro
and remove the INTERNAL_SYSCALL_DECL usage.
Checked with a build against all affected ABIs.
With all Linux ABIs using the expected Linux kABI to indicate
syscalls errors, there is no need to replicate the INLINE_SYSCALL.
The generic Linux sysdep.h includes errno.h even for !__ASSEMBLER__,
which is ok now and it allows cleanup some archaic code that assume
otherwise.
Checked with a build against all affected ABIs.
The riscv INTERNAL_SYSCALL macro might clobber the register
parameter if the argument itself might clobber any register (a function
call for instance).
This patch fixes it by using temporary variables for the expressions
between the register assignments (as indicated by GCC documentation,
6.47.5.2 Specifying Registers for Local Variables).
It is similar to the fix done for MIPS (bug 25523).
Checked with riscv64-linux-gnu-rv64imafdc-lp64d build.
The microblaze INTERNAL_SYSCALL macro might clobber the register
parameter if the argument itself might clobber any register (a function
call for instance).
This patch fixes it by using temporary variables for the expressions
between the register assignments (as indicated by GCC documentation,
6.47.5.2 Specifying Registers for Local Variables).
It is similar to the fix done for MIPS (bug 25523).
Checked with microblaze-linux-gnu and microblazeel-linux-gnu build.
It changes the nios INTERNAL_SYSCALL_RAW macro to return a negative
value instead of the 'r2' register value on the 'err' macro argument.
The macro INTERNAL_SYSCALL_DECL is no longer required, and the
INTERNAL_SYSCALL_ERROR_P macro follows the other Linux kABIs.
Checked with a build against nios2-linux-gnu.
It changes the mips INTERNAL_SYSCALL* and internal_syscall* macros
to return a negative value instead of the 'a3' register value on then
'err' macro argument.
The macro INTERNAL_SYSCALL_DECL is no longer required, and the
INTERNAL_SYSCALL_ERROR_P macro follows the other Linux kABIs.
The redefinition of INTERNAL_VSYSCALL_CALL is also no longer
required.
Checked on mips64-linux-gnu, mips64n32-linux-gnu, and mips-linux-gnu.
The mips64 Linux syscall macros only differs argument type and
the requirement of sign-extending values on n32. The headers
are consolidate by parameterizing the arguments with a new type,
__syscall_arg_t, and by defining the ARGIFY for n64.
Also, the generic unix mips64 sysdep is essentially the same,
only the load instruction need to be adjusted depending of the
ABI.
Checked on mips64-linux-gnu and mips64n32-linux-gnu.
It changes the ia64 INTERNAL_SYSCALL_NCS macro to return a negative
value instead of the 'r10' register value on the 'err' macro argument.
The macro INTERNAL_SYSCALL_DECL is no longer required, and the
INTERNAL_SYSCALL_ERROR_P macro follows the other Linux kABIs.
Checked on ia64-linux-gnu.
It highly unlikely that alpha will be ported to anything else than
Linux, so this patch moves the generic unix syscall definition to
Linux and adapt it to Linux kernel ABI.
It changes the internal_syscall* macros to return a negative value
instead of the '$19' register value on the 'err' macro argument.
The macro INTERNAL_SYSCALL_DECL is no longer required, and the
INTERNAL_SYSCALL_ERROR_P macro follows the other Linux kABIs.
Checked on alpha-linux-gnu.
The sparc INTERNAL_SYSCALL macro might clobber the register
parameter if the argument itself might clobber any register (a function
call for instance).
This patch fixes it by using temporary variables for the expressions
between the register assignments (as indicated by GCC documentation,
6.47.5.2 Specifying Registers for Local Variables).
It is similar to the fix done for MIPS (bug 25523).
Checked on sparc64-linux-gnu and sparcv9-linux-gnu.
It changes the sparc internal_syscall* macros to return a negative
value instead of the 'g1' register value in the 'err' macro argument.
The __SYSCALL_STRING macro is also changed to no set the 'g1'
value, since 'o1' already holds all the required information
to check if syscall has failed.
The macro INTERNAL_SYSCALL_DECL is no longer required, and the
INTERNAL_SYSCALL_ERROR_P macro follows the other Linux kABIs.
The redefinition of INTERNAL_VSYSCALL_CALL is also no longer
required.
Checked on sparc64-linux-gnu and sparcv9-linux-gnu. It fixes
the sporadic issues on sparc32 where clock_nanosleep does not
act as cancellation entrypoint.
It changes the powerpc INTERNAL_VSYSCALL_CALL and INTERNAL_SYSCALL_NCS
to return a negative value instead of the returning the CR value in
the 'err' macro argument.
The macro INTERNAL_SYSCALL_DECL is no longer required, and the
INTERNAL_SYSCALL_ERROR_P macro follows the other Linux kABIs.
Checked on powerpc64-linux-gnu, powerpc64le-linux-gnu, and
powerpc-linux-gnu-power4.
The diferences between powerpc64{le} and powerpc32 Linux sysdep.h
are:
1. On both vDSO and syscall macros the volatile registers r9, r10,
r11, and r12 are used as input operands on powerpc32 and as
clobber registers on powerpc64. However the outcome is essentially
the same, it advertise the register might be clobbered by the
kernel (although Linux won't leak register information to userland
in such case).
2. The LOADARGS* macros uses a different size to check for invalid
types.
3. The pointer mangling support guard pointer loading uses ABI
specific instruction and register.
This patch consolidates on only one sysdep by using the the powerpc64
version as default and add the adjustments required for powerpc32.
Checked on powerpc64-linux-gnu, powerpc64le-linux-gnu, and
powerpc-linux-gnu-power4.
1. getcontext and swapcontext are updated to save the caller's shadow
stack pointer and return address.
2. setcontext and swapcontext are updated to restore shadow stack and
jump to new context directly.
3. makecontext is updated to allocate a new shadow stack and set the
caller's return address to the helper code, L(exitcode).
4. Since we no longer save and restore EAX, ECX and EDX in getcontext,
setcontext and swapcontext, we can use them as scratch register slots
to enable CET in ucontext functions.
Since makecontext allocates a new shadow stack when making a new
context and kernel allocates a new shadow stack for clone/fork/vfork
syscalls, we track the current shadow stack base. In setcontext and
swapcontext, if the target shadow stack base is the same as the current
shadow stack base, we unwind the shadow stack. Otherwise it is a stack
switch and we look for a restore token.
We enable shadow stack at run-time only if program and all used shared
objects, including dlopened ones, are shadow stack enabled, which means
that they must be compiled with GCC 8 or above and glibc 2.28 or above.
We need to save and restore shadow stack only if shadow stack is enabled.
When caller of getcontext, setcontext, swapcontext and makecontext is
compiled with smaller ucontext_t, shadow stack won't be enabled at
run-time. We check if shadow stack is enabled before accessing the
extended field in ucontext_t.
Tested on i386 CET/non-CET machines.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
We can't include sysdep.h in the test case (it introduces lots of
strange failures) so __NR_futex isn't redifined to __NR_futex_time64 by
64-bit time_t 32-bit archs (y2038 safe).
To allow the test to pass let's just do the __NR_futex_time64 syscall if
we don't have __NR_futex defined.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The 32-bit protection key behavior is somewhat unclear on 32-bit powerpc,
so this change is restricted to the 64-bit variants.
Flag translation is needed because of hardware differences between the
POWER implementation (read and write flags) and the Intel implementation
(write and read+write flags).
A non-ascii character in the installed headers leads now to:
error: failure to convert ascii to UTF-8
Such a finding in s390 specific fenv.h leads to fails in GCC testsuite.
See glibc commit 08aea89ef6.
Adding this gcc option also to our tests was proposed by Florian Weimer.
This change also found a hit in resource.h where now "microseconds" is used.
I've adjusted all the resource.h files.
I've used the following command to check for further hits in headers.
LC_ALL=C find -name "*.h" -exec grep -PHn "[\x80-\xFF]" {} \;
Tested on s390x and x86_64.
Reviewed-by: Zack Weinberg <zackw@panix.com>
By undef strong_alias on alpha implementation, the
default_symbol_version macro becomes an empty macro on static build.
It fixes the issue introduced at c953219420.
Checked on alpha-linux-gnu with a 'make check run-built-tests=no'.
According to [gcc documentation][1], temporary variables must be used for
the desired content to not be call-clobbered.
Fix the Linux inline syscall templates by adding temporary variables,
much like what x86 did before
(commit 381a0c26d7).
Tested with gcc 9.2.0, both cross-compiled and natively on Loongson
3A4000.
[1]: https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html
It makes alpha no longer reports information about a system-wide
time zone and moves the version logic on the alpha implementation.
Checked on a build and check-abi for alpha-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Linux 5.5 renames RWF_WRITE_LIFE_NOT_SET to RWH_WRITE_LIFE_NOT_SET,
with the old name kept as an alias. This patch makes the
corresponding change in glibc.
Tested for x86_64.
The O_PATH-based fchmodat emulation will rely on the fact that closing
an O_PATH descriptor never releases POSIX advisory locks, so this
commit adds a test case for this behavior.
This patch provides new __settimeofday64 explicit 64 bit function for setting
64 bit time in the kernel (by internally calling __clock_settime64).
Moreover, a 32 bit version - __settimeofday has been refactored to internally
use __settimeofday64.
The __settimeofday is now supposed to be used on systems still supporting 32
bit time (__TIMESIZE != 64) - hence the necessary conversion of struct
timeval to 64 bit struct __timespec64.
Internally the settimeofday uses __settimeofday64. This patch is necessary
for having architectures with __WORDSIZE == 32 Y2038 safe.
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 proper usage of both __settimeofday64 and __settimeofday.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The name 'valid_timeval64_to_timeval' suggest conversion of struct
__timeval64 to struct timeval (as in ./include/time.h).
As on the alpha the struct timeval supports 64 bit time, it seems more
feasible to emphasis struct timeval32 in the conversion function name.
Hence the helper function naming change to 'valid_timeval_to_timeval32'.
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Without this patch the naming convention for functions to convert
struct timeval32 to struct timeval (which supports 64 bit time on Alpha) was
a bit misleading. The name 'valid_timeval_to_timeval64' suggest conversion
of struct timeval to struct __timeval64 (as in ./include/time.h).
As on alpha the struct timeval supports 64 bit time it seems more readable
to emphasis struct timeval32 in the conversion function name.
Hence the helper function naming change to 'valid_timeval32_to_timeval'.
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The __suseconds64_t type is supposed to be the 64 bit type across all
architectures.
It would be mostly used internally in the glibc - however, when passed to
Linux kernel (very unlikely), if necessary, it shall be converted to 32
bit type (i.e. __suseconds_t)
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch updates the kernel version in the test tst-mman-consts.py
to 5.5. (There are no new constants covered by this test in 5.5 that
need any other header changes.)
Tested with build-many-glibcs.py.
Linux 5.5 has no new syscalls to add to syscall-names.list, but it
does newly enable the clone3 syscall for AArch64. This patch updates
the kernel version listed in syscall-names.list and regenerates the
AArch64 arch-syscall.h.
Tested with build-many-glibcs.py.
This patch provides new instance of Linux specific timespec_get.c file placed
in ./sysdeps/unix/sysv/linux/.
When compared to this file version from ./time directory, it provides
__timespec_get64 explicit 64 bit function for getting 64 bit time in the
struct __timespec64 (for compilation using C11 standard).
Moreover, a 32 bit version - __timespec_get internally uses
__timespec_get64.
The __timespec_get is now supposed to be used on systems still supporting 32
bit time (__TIMESIZE != 64) - hence the necessary conversion to 32 bit struct
timespec.
Internally the timespec_get uses __clock_gettime64. This patch is necessary
for having architectures with __WORDSIZE == 32 Y2038 safe.
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 proper usage of both __timespec_get64 and __timespec_get.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The functions __timer_gettime64 and __timer_settime64 live in librt, not
libc. Use proper hidden aliases so that the callers do not need to set up
the PLT register.
Fixes commits cae1635a70 ("y2038: linux: Provide __timer_settime64
implementation") and 562cdc19c7 ("y2038: linux: Provide __timer_gettime64
implementation").
This patch replaces auto generated wrapper (as described in
sysdeps/unix/sysv/linux/syscalls.list) for sched_rr_get_interval with one which
adds extra support for reading 64 bit time values on machines with
__TIMESIZE != 64.
There is no functional change for architectures already supporting 64 bit
time ABI.
The sched_rr_get_interval declaration in ./include/sched.h is not followed by
corresponding libc_hidden_proto(), so it has been assumed that newly introduced
syscall wrapper doesn't require libc_hidden_def() (which has been added by
template used with auto generation script).
Moreover, the code for building sched_rr_gi.c file is already placed in
./posix/Makefiles, so there was no need to add it elsewhere.
Performed tests and validation are the same as for timer_gettime() conversion
(sysdeps/unix/sysv/linux/timer_gettime.c).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch replaces auto generated wrapper (as described in
sysdeps/unix/sysv/linux/syscalls.list) for timerfd_settime with one which
adds extra support for reading and writing from Linux kernel 64 bit time
values on machines with __TIMESIZE != 64.
There is no functional change for archs already supporting 64 bit time ABI.
This patch is conceptually identical to timer_settime conversion already
done in sysdeps/unix/sysv/linux/timer_settime.c.
Please refer to corresponding commit message for detailed description of
introduced functions and the testing procedure.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
---
Changes for v4:
- Update date from 2019 to 2020
Changes for v3:
- Add missing libc_hidden_def()
Changes for v2:
- Remove "Contributed by" from the file header
- Remove early check for (fd < 0) in __timerfd_settime64 as the fd
correctness check is already done in Linux kernel
- Add single descriptive comment line to provide concise explanation
of the code
This patch replaces auto generated wrapper (as described in
sysdeps/unix/sysv/linux/syscalls.list) for timerfd_gettime with one which
adds extra support for reading 64 bit time values on machines with
__TIMESIZE != 64.
There is no functional change for architectures already supporting 64 bit
time ABI.
This patch is conceptually identical to timer_gettime conversion already
done in sysdeps/unix/sysv/linux/timer_gettime.c.
Please refer to corresponding commit message for detailed description of
introduced functions and the testing procedure.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
---
Changes for v4:
- Update date from 2019 to 2020
Changes for v3:
- Add missing libc_hidden_def()
Changes for v2:
- Remove "Contributed by" from the file header
- Remove early check for (fd < 0) in __timerfd_gettime64 as the fd
correctness check is already done in Linux kernel
- Add single descriptive comment line to provide concise explanation
of the code
The generic implementation is suffice since __NR_exit_group is always
support and i386 does define ABORT_INSTRUCTION.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
On i386, since EAX, ECX and EDX are caller-saved, there are no need
to save and restore EAX, ECX and EDX in getcontext, setcontext and
swapcontext. They just need to clear EAX on success. The extra
scratch registers are needed to enable CET.
Tested on i386.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This test was failing in some powerpc systems as it was not checking
for ENOSPC return.
As said on the Linux man-pages and can be observed by the implementation
at mm/mprotect.c in the Linux Kernel source. The syscall pkey_alloc can
return EINVAL or ENOSPC. ENOSPC will indicate either that all keys are
in use or that the kernel does not support pkeys.
Reviewed-by: Gabriel F. T. Gomes <gabriel@inconstante.net.br>
GCC 10.0 enabled -fno-common by default and this started to point that
__cache_line_size had been implemented in 2 different places: loader and
libc.
In order to avoid this duplication, the libc variable has been removed
and the loader variable is moved to rtld_global_ro.
File sysdeps/unix/sysv/linux/powerpc/dl-auxv.h has been added in order
to reuse code for both static and dynamic linking scenarios.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Initialize dl_auxv, dl_hwcap and dl_hwcap2 in rtld_global_ro for DSOs
that have been statically dlopen'ed.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
This patch avoid probing the __NR_clock_getttime64 syscall each time
__clock_gettime64 is issued on a kernel without 64 bit time support.
Once ENOSYS is obtained, only 32-bit clock_gettime are used.
The following snippet:
clock_getres (CLOCK_REALTIME, &(struct timespec) { 0 });
clock_getres (CLOCK_MONOTONIC, &(struct timespec) { 0 });
clock_getres (CLOCK_BOOTTIME, &(struct timespec) { 0 });
clock_getres (20, &(struct timespec) { 0 });
On a kernel without 64 bit time support issues the syscalls:
syscall_0x196(0, 0xffb83330, [...]) = -1 ENOSYS (Function not implemented)
clock_getres(CLOCK_REALTIME, {tv_sec=0, tv_nsec=1}) = 0
clock_getres(CLOCK_MONOTONIC, {tv_sec=0, tv_nsec=1}) = 0
clock_getres(CLOCK_BOOTTIME, {tv_sec=0, tv_nsec=1}) = 0
Checked on i686-linux-gnu on 4.15 kernel.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
No architecture currently defines the vDSO symbol. On archictures
with 64-bit time_t the HAVE_CLOCK_GETRES_VSYSCALL is renamed to
HAVE_CLOCK_GETRES64_VSYSCALL, it simplifies clock_gettime code.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
It was added on Linux 5.3 (commit 22ca962288c0a).
Checked on i686-linux-gnu with 5.3.0 kernel.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
This patch avoid probing the __NR_clock_getttime64 syscall each time
__clock_gettime64 is issued on a kernel without 64 bit time support.
Once ENOSYS is obtained, only 32-bit clock_gettime are used.
The following snippet:
clock_gettime (CLOCK_REALTIME, &(struct timespec) { 0 });
clock_gettime (CLOCK_MONOTONIC, &(struct timespec) { 0 });
clock_gettime (CLOCK_BOOTTIME, &(struct timespec) { 0 });
clock_gettime (20, &(struct timespec) { 0 });
On a kernel without 64 bit time support and with vDSO support results
on the following syscalls:
syscall_0x193(0, 0xff87ba30, [...]) = -1 ENOSYS (Function not implemented)
clock_gettime(CLOCK_BOOTTIME, {tv_sec=927082, tv_nsec=474382032}) = 0
clock_gettime(0x14 /* CLOCK_??? */, 0xff87b9f8) = -1 EINVAL (Invalid argument)
While on a kernel without vDSO support:
syscall_0x193(0, 0xbec95550, 0xb6ed2000, 0x1, 0xbec95550, 0) = -1 (errno 38)
clock_gettime(CLOCK_REALTIME, {tv_sec=1576615930, tv_nsec=638250162}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=1665478, tv_nsec=638779620}) = 0
clock_gettime(CLOCK_BOOTTIME, {tv_sec=1675418, tv_nsec=292932704}) = 0
clock_gettime(0x14 /* CLOCK_??? */, 0xbec95530) = -1 EINVAL (Invalid argument)
Checked on i686-linux-gnu on 4.15 kernel and on a 5.3 kernel.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
No architecture currently defines the vDSO symbol. On architectures
with 64-bit time_t the HAVE_CLOCK_GETTIME_VSYSCALL is renamed to
HAVE_CLOCK_GETTIME64_VSYSCALL, it simplifies clock_gettime code.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
This patch moves the vDSO setup from libc to loader code, just after
the vDSO link_map setup. For static case the initialization
is moved to _dl_non_dynamic_init instead.
Instead of using the mangled pointer, the vDSO data is set as
attribute_relro (on _rtld_global_ro for shared or _dl_vdso_* for
static). It is read-only even with partial relro.
It fixes BZ#24967 now that the vDSO pointer is setup earlier than
malloc interposition is called.
Also, vDSO calls should not be a problem for static dlopen as
indicated by BZ#20802. The vDSO pointer would be zero-initialized
and the syscall will be issued instead.
Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu,
arm-linux-gnueabihf, powerpc64le-linux-gnu, powerpc64-linux-gnu,
powerpc-linux-gnu, s390x-linux-gnu, sparc64-linux-gnu, and
sparcv9-linux-gnu. I also run some tests on mips.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The IFUNC bypass to vDSO is used when USE_IFUNC_TIME is set.
Currently powerpc and x86 defines it. Otherwise the generic
implementation is used, which calls clock_gettime.
Checked on powerpc64le-linux-gnu, powerpc64-linux-gnu,
powerpc-linux-gnu-power4, x86_64-linux-gnu, and i686-linux-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The IFUNC bypass to vDSO is used when USE_IFUNC_GETTIMEOFDAY is set.
Currently aarch64, powerpc*, and x86 defines it. Otherwise the
generic implementation is used, which calls clock_gettime.
Checked on aarch64-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, powerpc-linux-gnu-power4, x86_64-linux-gnu,
and i686-linux-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The clock_getres is a new implementation added on Linux 5.4
(abed3d826f2f).
Checked with a build against mips-linux-gnu and mips64-linux-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Add the missing time and clock_getres vDSO symbol names on x86.
For time, the iFUNC already uses expected name so it affects only
the static build.
The clock_getres is a new implementation added on Linux 5.3
(f66501dc53e72).
Checked on x86-linux-gnu and i686-linux-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The auto-generated vDSO call shows some issues:
- It requires sync the auto-generated C file with current glibc
implementation;
- It still uses symbol redirections hacks where libc-symbols.h
provide macros that uses compiler builtins
(libc_ifunc_redirected for instance);
- It does not handle all required compiler handling
(inhibit_stack_protector on iFUNC resolver).
- No architecure uses it.
Checked with a build against all major ABIs.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
This is the only use of auto-generation syscall which uses a vDSO
plus IFUNC and the current x86 generic implementation already covers
the expected semantic.
Checked on x86_64-linux-gnu-x32.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
As indicated on libc-help [1] the ec138c67cb commit broke 32-bit
builds when configured with --enable-kernel=5.1 or higher. The
scenario 10 from [2] might also occur in this configuration and
INLINE_VSYSCALL will try to use the vDSO symbol and
HAVE_CLOCK_GETTIME64_VSYSCALL does not set HAVE_VSYSCALL prior its
usage.
Also, there is no easy way to just enable the code to use one
vDSO symbol since the macro INLINE_VSYSCALL is redefined if
HAVE_VSYSCALL is set.
Instead of adding more pre-processor handling and making the code
even more convoluted, this patch removes the requirement of defining
HAVE_VSYSCALL before including sysdep-vdso.h to enable vDSO usage.
The INLINE_VSYSCALL is now expected to be issued inside a
HAVE_*_VSYSCALL check, since it will try to use the internal vDSO
pointers.
Both clock_getres and clock_gettime vDSO code for time64_t were
removed since there is no vDSO setup code for the symbol (an
architecture can not set HAVE_CLOCK_GETTIME64_VSYSCALL).
Checked on i686-linux-gnu (default and with --enable-kernel=5.1),
x86_64-linux-gnu, aarch64-linux-gnu, and powerpc64le-linux-gnu.
I also checked against a build to mips64-linux-gnu and
sparc64-linux-gnu.
[1] https://sourceware.org/ml/libc-help/2019-12/msg00014.html
[2] https://sourceware.org/ml/libc-alpha/2019-12/msg00142.html
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The result of INTERNAL_SYSCALL_CANCEL should be checked with
macros INTERNAL_SYSCALL_ERROR_P and INTERNAL_SYSCALL_ERRNO instead
of comparing the result directly.
Checked on powerpc-linux-gnu.
Since the switch away from auto-generated wrappers for these system
calls, the kludge is already included in the C source file of the
system call wrapper.
Use <arch-syscall.h> instead of <asm/unistd.h> to obtain the system
call numbers. A few direct includes of <asm/unistd.h> need to be
removed (if the system call numbers are already provided indirectly
by <sysdep.h>) or replaced with <sys/syscall.h>.
Current Linux headers for alpha define the required system call names,
so most of the _NR_* hacks are no longer needed. For the 32-bit arm
architecture, eliminate the INTERNAL_SYSCALL_ARM macro, now that we
have regular system call names for cacheflush and set_tls. There are
more such cleanup opportunities for other architectures, but these
cleanups are required to avoid macro redefinition errors during the
build.
For ia64, it is desirable to use <asm/break.h> directly to obtain
the break number for system calls (which is not a system call number
itself). This requires replacing __BREAK_SYSCALL with
__IA64_BREAK_SYSCALL because the former is defined as an alias in
<asm/unistd.h>, but not in <asm/break.h>.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The new tables are currently only used for consistency checks
with the installed kernel headers and the architecture-independent
system call names table. They are based on Linux 5.4.
The goal is to use these architecture-specific tables to ensure
that system call wrappers are available irrespective of the version
of the installed kernel headers.
The tables are formatted in the form of C header files so that they
can be used directly in an #include directive, without external
preprocessing. (External preprocessing of a plain table file
would introduce cross-subdirectory dependency issues.) However,
the intent is that they can still be treated as tables and can be
processed by simple tools.
The irregular system call names on 32-bit arm add a complication.
The <fixup-asm-unistd.h> header is introduced to work around that,
and the system calls are listed under regular names in the
<arch-syscall.h> file.
A make target, update-syscalls-list, is added to patch the glibc
sources with data from the current kernel headers.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
I've updated copyright dates in glibc for 2020. This is the patch for
the changes not generated by scripts/update-copyrights and subsequent
build / regeneration of generated files. As well as the usual annual
updates, mainly dates in --version output (minus libc.texinfo which
previously had to be handled manually but is now successfully updated
by update-copyrights), there is a fix to
sysdeps/unix/sysv/linux/powerpc/bits/termios-c_lflag.h where a typo in
the copyright notice meant it failed to be updated automatically.
Please remember to include 2020 in the dates for any new files added
in future (which means updating any existing uncommitted patches you
have that add new files to use the new copyright dates in them).
On platforms where long double has IEEE binary128 format as a third
option (initially, only powerpc64le), many exported functions are
redirected to their __*ieee128 equivalents. This redirection is
provided by installed headers such as stdio-ldbl.h, and is supposed to
work correctly with user code.
However, during the build of glibc, similar redirections are employed,
in internal headers, such as include/stdio.h, in order to avoid extra
PLT entries. These redirections conflict with the redirections to
__*ieee128, and must be avoided during the build. This patch protects
the second redirections with a test for __LONG_DOUBLE_USES_FLOAT128, a
new macro that is defined to 1 when functions that deal with long double
typed values reuses the _Float128 implementation (this is currently only
true for powerpc64le).
Tested for powerpc64le, x86_64, and with build-many-glibcs.py.
Co-authored-by: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
All architectures now uses the Linux generic implementation which
uses __NR_rt_sigprocmask.
Checked on x86_64-linux-gnu, sparc64-linux-gnu, ia64-linux-gnu,
s390x-linux-gnu, and alpha-linux-gnu.
The functions do not fail regardless of the argument value. Also, for
Linux the return value is not correct on some platforms due the missing
usage of INTERNAL_SYSCALL_ERROR_P / INTERNAL_SYSCALL_ERRNO macros.
Checked on x86_64-linux-gnu, i686-linux-gnu, and sparc64-linux-gnu.
Kunpeng processer is a 64-bit Arm-compatible CPU released by Huawei,
and we have already signed a copyright assignement with the FSF.
This patch adds its to cpu list, and related macro for IFUNC.
Checked on aarch64-linux-gnu.
Reviewed-by: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
If the wait4 syscall is not available (such as y2038 safe 32-bit
systems) waitid should be used instead. However prior Linux 5.4
waitid is not a full superset of other wait syscalls, since it
does not include support for waiting for the current process group.
It is possible to emulate wait4 by issuing an extra syscall to get
the current process group, but it is inherent racy: after the current
process group is received and before it is passed to waitid a signal
could arrive causing the current process group to change.
So waitid is used if wait4 is not defined iff the build is
enabled with a minimum kernel if 5.4+. The new assume
__ASSUME_WAITID_PID0_P_PGID is added and an error is issued if waitid
can not be implemented by either __NR_wait4 or
__NR_waitid && __ASSUME_WAITID_PID0_P_PGID.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Co-authored-by: Alistair Francis <alistair.francis@wdc.com>
The POSIX implementation is used as default and both BSD and Linux
version are removed. It simplifies the implementation for
architectures that do not provide either __NR_waitpid or
__NR_wait4.
Checked on x86_64-linux-gnu and powerpc64le-linux-gnu.
It enables and disables cancellation with pthread_setcancelstate
before calling the waitpid. It simplifies the waitpid implementation
for architectures that do not provide either __NR_waitpid or
__NR_wait4.
Checked on x86_64-linux-gnu.
The posix_spawn on sparc issues invalid sigprocmask calls:
rt_sigprocmask(0xffe5e15c /* SIG_??? */, ~[], 0xffe5e1dc, 8) = -1 EINVAL (Invalid argument)
Which make support/tst-support_capture_subprocess fails with random
output (due the child signal being wrongly captured by the parent).
Tracking the culprit it seems to be a wrong code generation in the
INTERNAL_SYSCALL due the automatic sigset_t used on
__libc_signal_block_all:
return INTERNAL_SYSCALL (rt_sigprocmask, err, 4, SIG_BLOCK, &SIGALL_SET,
set, _NSIG / 8);
Where SIGALL_SET is defined as:
((__sigset_t) { .__val = {[0 ... _SIGSET_NWORDS-1 ] = -1 } })
Building the expanded __libc_signal_block_all on sparc64 with recent
compiler (gcc 8.3.1 and 9.1.1):
#include <signal>
int
_libc_signal_block_all (sigset_t *set)
{
INTERNAL_SYSCALL_DECL (err);
return INTERNAL_SYSCALL (rt_sigprocmask, err, 4, SIG_BLOCK, &SIGALL_SET,
set, _NSIG / 8);
}
The first argument (SIG_BLOCK) is not correctly set on 'o0' register:
__libc_signal_block_all:
save %sp, -304, %sp
add %fp, 1919, %o0
mov 128, %o2
sethi %hi(.LC0), %o1
call memcpy, 0
or %o1, %lo(.LC0), %o1
add %fp, 1919, %o1
mov %i0, %o2
mov 8, %o3
mov 103, %g1
ta 0x6d;
bcc,pt %xcc, 1f
mov 0, %g1
sub %g0, %o0, %o0
mov 1, %g1
1: sra %o0, 0, %i0
return %i7+8
nop
Where if SIGALL_SET is defined a const object, gcc correctly sets the
expected kernel argument in correct register:
sethi %hi(.LC0), %o1
call memcpy, 0
or %o1, %lo(.LC0), %o1
-> mov 1, %o0
add %fp, 1919, %o1
Another possible fix is use a static const object. Although there
should not be a difference between a const compound literal and a static
const object, the gcc C99 status page [1] has a note stating that this
optimization is not implemented:
"const-qualified compound literals could share storage with each
other and with string literals, but currently don't.".
This patch fixes it by moving both sigset_t that represent the
signal sets to static const data object. It generates slight better
code where the object reference is used directly instead of a stack
allocation plus the content materialization.
Checked on x86_64-linux-gnu, i686-linux-gnu, and sparc64-linux-gnu.
[1] https://gcc.gnu.org/c99status.html
GCC 10 (PR 91233) won't silently allow registers that are not architecturally
available to be present in the clobber list anymore, resulting in build failure
for mips*r6 targets in form of:
...
.../sysdep.h:146:2: error: the register ‘lo’ cannot be clobbered in ‘asm’ for the current target
146 | __asm__ volatile ( \
| ^~~~~~~
This is because base R6 ISA doesn't define hi and lo registers w/o DSP extension.
This patch provides the alternative definitions of __SYSCALL_CLOBBERS for r6
targets that won't include those registers.
* sysdeps/unix/sysv/linux/mips/mips32/sysdep.h (__SYSCALL_CLOBBERS): Exclude
hi and lo from the clobber list for __mips_isa_rev >= 6.
* sysdeps/unix/sysv/linux/mips/mips64/n32/sysdep.h (__SYSCALL_CLOBBERS): Likewise.
* sysdeps/unix/sysv/linux/mips/mips64/n64/sysdep.h (__SYSCALL_CLOBBERS): Likewise.
This patch adds the missing __libpthread_version_placeholder for
GLIBC_2.2.6 version from the nanosleep implementation move from
libpthread to libc (79a547b162).
It also fixes the wrong compat symbol definitions added by changing
back the version used on vfork check and remove the
__libpthread_version_placeholder added on some ABI (4f4bb489e0).
The __libpthread_version_placeholder is also refactored to make it
simpler to add new compat_symbols by adding a new macro
compat_symbol_unique which uses the compiler extension __COUNTER__
to generate unique strong alias to be used with compat_symbol.
Checked with a updated-abi on the all affected abis of the nanosleep
move.
Change-Id: I347a4dbdc931bb42b359456932dd1e17aa4d4078
This patch provides new __timer_settime64 explicit 64 bit function for setting
flags, interval and value of specified timer.
Moreover, a 32 bit version - __timer_settime has been refactored to internally
use __timer_settime64.
The __timer_settime is now supposed to be used on systems still supporting 32
bit time (__TIMESIZE != 64) - hence the necessary conversion to 64 bit struct
__timespec64 from struct timespec (and opposite when old_value pointer is
provided).
The new __timer_settime64 syscall available from Linux 5.1+ has been used, when
applicable.
The original INLINE_SYSCALL() macro has been replaced with
INLINE_SYSCALL_CALL() to avoid explicit passing the number of arguments.
Build tests:
- The code has been tested on x86_64/x86 (native compilation):
make PARALLELMFLAGS="-j8" && make check PARALLELMFLAGS="-j8" && \\
make xcheck PARALLELMFLAGS="-j8"
- The glibc has been build tested (make PARALLELMFLAGS="-j8") for
x86 (i386), x86_64-x32, and armv7
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
- Use of cross-test-ssh.sh for ARM (armv7):
make PARALLELMFLAGS="-j8" test-wrapper='./cross-test-ssh.sh root@192.168.7.2' xcheck
Linux kernel, headers and minimal kernel version for glibc build test
matrix:
- Linux v5.1 (with timer_settime64) and glibc build with v5.1 as
minimal kernel version (--enable-kernel="5.1.0")
The __ASSUME_TIME64_SYSCALLS flag defined.
- Linux v5.1 and default minimal kernel version
The __ASSUME_TIME64_SYSCALLS not defined, but kernel supports timer_settime64
syscall.
- Linux v4.19 (no timer_settime64 support) with default minimal kernel version
for contemporary glibc (3.2.0)
This kernel doesn't support timer_settime64 syscall, so the fallback to
timer_settime is tested.
Above tests were performed with Y2038 redirection applied as well as without
(so the __TIMESIZE != 64 execution path is checked as well).
No regressions were observed.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch provides new __timer_gettime64 explicit 64 bit function for reading
status of specified timer. To be more precise - the remaining time and interval
set with timer_settime.
Moreover, a 32 bit version - __timer_gettime has been refactored to internally
use __timer_gettime64.
The __timer_gettime is now supposed to be used on systems still supporting 32
bit time (__TIMESIZE != 64) - hence the necessary conversion from 64 bit struct
__timespec64 to struct timespec.
The new __timer_gettime64 syscall available from Linux 5.1+ has been used, when
applicable.
The original INLINE_SYSCALL() macro has been replaced with
INLINE_SYSCALL_CALL() to avoid explicit passing the number of arguments.
Build tests:
- The code has been tested on x86_64/x86 (native compilation):
make PARALLELMFLAGS="-j8" && make check PARALLELMFLAGS="-j8" && \\
make xcheck PARALLELMFLAGS="-j8"
- The glibc has been build tested (make PARALLELMFLAGS="-j8") for
x86 (i386), x86_64-x32, and armv7
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
- Use of cross-test-ssh.sh for ARM (armv7):
make PARALLELMFLAGS="-j8" test-wrapper='./cross-test-ssh.sh root@192.168.7.2' xcheck
Linux kernel, headers and minimal kernel version for glibc build test
matrix:
- Linux v5.1 (with timer_gettime64) and glibc build with v5.1 as
minimal kernel version (--enable-kernel="5.1.0")
The __ASSUME_TIME64_SYSCALLS flag defined.
- Linux v5.1 and default minimal kernel version
The __ASSUME_TIME64_SYSCALLS not defined, but kernel supports timer_gettime64
syscall.
- Linux v4.19 (no timer_gettime64 support) with default minimal kernel version
for contemporary glibc (3.2.0)
This kernel doesn't support timer_gettime64 syscall, so the fallback to
timer_gettime is tested.
Above tests were performed with Y2038 redirection applied as well as without
(so the __TIMESIZE != 64 execution path is checked as well).
No regressions were observed.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The x86_64 specific timer_settime implementation (from
./linux/x86_64/timer_settime.c) reused the Linux generic one (from
./linux/timer_settime.c) to implement handling some compatible timers
(previously defined in librt, now in libc).
As the generic implementation now is going to also support new (available
from Linux 5.1+) timer_settime64 syscall, those two implementations have
been decoupled for easier conversion.
The original INLINE_SYSCALL() macro has been replaced with
INLINE_SYSCALL_CALL() to avoid explicit passing the number of arguments.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The x86_64 specific timer_gettime implementation (from
./linux/x86_64/timer_gettime.c) reused the Linux generic one (from
./linux/timer_gettime.c) to implement handling some compatible timers
(previously defined in librt, now in libc).
As the generic implementation now is going to also support new (available
from Linux 5.1+) timer_gettime64 syscall, those two implementations have
been decoupled for easier conversion.
The original INLINE_SYSCALL() macro has been replaced with
INLINE_SYSCALL_CALL() to avoid explicit passing the number of arguments.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
In commit 3dd4d40b420846dd35869ccc8f8627feef2cff32 ("xfs: Sanity check
flags of Q_XQUOTARM call"), Linux 5.4 added checking for the flags
argument, causing the test to fail due to too restrictive test
expectations.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
With the clock_gettime64 call we prefer to use vDSO. There is no call
to clock_gettime64 on glibc with older headers and kernel 5.1+ if it
doesn't support vDSO.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Add support for the clock_gettim64 vDSO calls. These are protected by
the HAVE_CLOCK_GETTIME64_VSYSCALL define.
HAVE_CLOCK_GETTIME64_VSYSCALL should be defined for 32-bit platforms
(WORDSIZE == 32) that only run on the 5.1 kernel or later. WORDSIZE ==
64 platforms can use #define __vdso_clock_gettime64 __vdso_clock_gettime
and use the __vdso_clock_gettime syscall as they don't have a
__vdso_clock_gettime64 call.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
ld.so symbols to be overriden by libc need to be extern to really get
overriden. __access happens to have never been exposed, putting it to
GLIBC_PRIVATE.
ld.so symbols to be overriden by libc need to be extern to really get
overriden. __getcwd happens to have never been exposed, putting it to
GLIBC_PRIVATE.
This patch updates the kernel version in the test tst-mman-consts.py
to 5.4. (There are no new constants covered by this test in 5.4 that
need any other header changes.)
Tested with build-many-glibcs.py.
Linux 5.4 changes the SOMAXCONN value from 128 to 4096 (this isn't in
a uapi header; various constants related to the kernel/userspace
interface, including this one, are in the non-uapi linux/socket.h
header).
This patch increases the value in glibc. As I understand it, it is
safe to use a higher value even with older kernels (the kernel will
simply adjust the value passed to listen to be no more than the value
supported in the kernel), and SOMAXCONN is actually only a default for
a sysctl value in the kernel that can be changed at runtime. So I
think updating the value in glibc is a reasonable and safe thing to
do.
Tested for x86_64.
This patch updates syscall-names.list for Linux 5.4. There are no new
syscalls, so this is just a matter of updating the version number
listed in the file.
Tested with build-many-glibcs.py.
Linux 5.4 adds constants MADV_COLD and MADV_PAGEOUT (defined with the
same values on all architectures). This patch adds them to
bits/mman-linux.h.
Tested for x86_64.
This patch removes the arch-specific atomic instruction, relying on
compiler builtins. The __sparc32_atomic_locks support is removed
and a configure check is added to check if compiler uses libatomic
to implement CAS.
It also removes the sparc specific sem_* and pthread_barrier_*
implementations. It in turn allows buidling against a LEON3/LEON4
sparcv8 target, although it will still be incompatible with generic
sparcv9.
Checked on sparcv9-linux-gnu and sparc64-linux-gnu. I also checked
with build against sparcv8-linux-gnu with -mcpu=leon3.
Tested-by: Andreas Larsson <andreas@gaisler.com>
Now that both pthread_mutex_t and pthread_rwlock_t static initializer
are parametrized in their own headers HPPA pthread.h is identical to
generic nptl one.
Checked on hppa-linux-gnu.
Change-Id: I236cfceb5656cfcce42c9e367a4f6803e2abd88b
This patch adds a new generic __pthread_rwlock_arch_t definition meant
to be used by new ports. Its layout mimics the current usage on some
64 bits ports and it allows some ports to use the generic definition.
The arch __pthread_rwlock_arch_t definition is moved from
pthreadtypes-arch.h to another arch-specific header (struct_rwlock.h).
Also the static intialization macro for pthread_rwlock_t is set to use
an arch defined on (__PTHREAD_RWLOCK_INITIALIZER) which simplifies its
implementation.
The default pthread_rwlock_t layout differs from current ports with:
1. Internal layout is the same for 32 bits and 64 bits.
2. Internal flag is an unsigned short so it should not required
additional padding to align for word boundary (if it is the case
for the ABI).
Checked with a build on affected abis.
Change-Id: I776a6a986c23199929d28a3dcd30272db21cd1d0
The current way of defining the common mutex definition for POSIX and
C11 on pthreadtypes-arch.h (added by commit 06be6368da) is
not really the best options for newer ports. It requires define some
misleading flags that should be always defined as 0
(__PTHREAD_COMPAT_PADDING_MID and __PTHREAD_COMPAT_PADDING_END), it
exposes options used solely for linuxthreads compat mode
(__PTHREAD_MUTEX_USE_UNION and __PTHREAD_MUTEX_NUSERS_AFTER_KIND), and
requires newer ports to explicit define them (adding more boilerplate
code).
This patch adds a new default __pthread_mutex_s definition meant to
be used by newer ports. Its layout mimics the current usage on both
32 and 64 bits ports and it allows most ports to use the generic
definition. Only ports that use some arch-specific definition (such
as hardware lock-elision or linuxthreads compat) requires specific
headers.
For 32 bit, the generic definitions mimic the other 32-bit ports
of using an union to define the fields uses on adaptive and robust
mutexes (thus not allowing both usage at same time) and by using a
single linked-list for robust mutexes. Both decisions seemed to
follow what recent ports have done and make the resulting
pthread_mutex_t/mtx_t object smaller.
Also the static intialization macro for pthread_mutex_t is set to use
a macro __PTHREAD_MUTEX_INITIALIZER where the architecture can redefine
in its struct_mutex.h if it requires additional fields to be
initialized.
Checked with a build on affected abis.
Change-Id: I30a22c3e3497805fd6e52994c5925897cffcfe13
The generic pselect implementation has the very specific race condition
that motived the creation of the pselect syscall (no atomicity in
signal mask set/reset). Using it as generic implementation is
counterproductive Also currently only microblaze uses it as fallback
when used on kernel prior 3.15.
This patch moves the generic implementation to a microblaze specific
one, sets the generic internal as a ENOSYS, and cleanups the Linux
generic implementation.
The microblaze implementation mimics the previous Linux generic one,
where it either uses pselect6 directly if __ASSUME_PSELECT or a
first try pselect6 then the fallback otherwise.
Checked on x86_64-linux-gnu and microblaze-linux-gnu.
This causes issues when using clang with -frewrite-includes to e.g.,
submit the translation unit to a distributed compiler.
In my case, I was building Firefox using sccache.
See [1] for a reduced test-case since I initially thought this was a
clang bug, and [2] for more context.
Apparently doing this is invalid C++ per [cpp.cond], which mentions [3]:
> The #ifdef and #ifndef directives, and the defined conditional
> inclusion operator, shall treat __has_include and __has_cpp_attribute
> as if they were the names of defined macros. The identifiers
> __has_include and __has_cpp_attribute shall not appear in any context
> not mentioned in this subclause.
[1]: https://bugs.llvm.org/show_bug.cgi?id=43982
[2]: https://bugs.llvm.org/show_bug.cgi?id=37990
[3]: http://eel.is/c++draft/cpp.cond#7.sentence-2
Change-Id: Id4b8ee19176a9e4624b533087ba870c418f27e60
This patch fixes the time64 support (added by 2e44b10b42) where it
misses the remaining argument updated if __NR_clock_nanosleep
returns EINTR.
Checked on i686-linux-gnu on 4.15 kernel (no time64 support) and
on 5.3 kernel (with time64 support).
Reviewed-by: Alistair Francis <alistair23@gmail.com>
This patch provides new __ppoll64 explicit 64 bit function for handling polling
events (with struct timespec specified timeout) for a set of file descriptors.
Moreover, a 32 bit version - __ppoll has been refactored to internally use
__ppoll64.
The __ppoll is now supposed to be used on systems still supporting 32 bit time
(__TIMESIZE != 64) - hence the necessary conversion to 64 bit struct
__timespec64.
The new ppoll_time64 syscall available from Linux 5.1+ has been used, when
applicable.
The Linux kernel checks if passed tv_nsec value overflows, so there is no need
to repeat it in the glibc.
When ppoll syscall on systems supporting 32 bit time ABI is used, the check is
performed if passed data (which may have 64 bit tv_sec) fits into 32 bit range.
Build tests:
- The code has been tested on x86_64/x86 (native compilation):
make PARALLELMFLAGS="-j8" && make check PARALLELMFLAGS="-j8" && \\
make xcheck PARALLELMFLAGS="-j8"
- The glibc has been build tested (make PARALLELMFLAGS="-j8") for
x86 (i386), x86_64-x32, and armv7
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
- Use of cross-test-ssh.sh for ARM (armv7):
make PARALLELMFLAGS="-j8" test-wrapper='./cross-test-ssh.sh root@192.168.7.2' xcheck
Linux kernel, headers and minimal kernel version for glibc build test
matrix:
- Linux v5.1 (with ppoll_time64) and glibc build with v5.1 as
minimal kernel version (--enable-kernel="5.1.0")
The __ASSUME_TIME64_SYSCALLS flag defined.
- Linux v5.1 and default minimal kernel version
The __ASSUME_TIME64_SYSCALLS not defined, but kernel supports ppoll_time64
syscall.
- Linux v4.19 (no ppoll_time64 support) with default minimal kernel version for
contemporary glibc
This kernel doesn't support ppoll_time64 syscall, so the fallback to ppoll is
tested.
Above tests were performed with Y2038 redirection applied as well as without
(so the __TIMESIZE != 64 execution path is checked as well).
No regressions were observed.
And related tests. These tests create a thread for each core, so
they may fail due to address space limitations with the default
stack size.
Change-Id: Ieef44a7731f58d3b7d6638cce4ccd31126647551
The clock_nanosleep syscall is not supported on newer 32-bit platforms (such
as RV32). To fix this issue let's use clock_nanosleep_time64 if it is
avaliable.
It just contains duplicated defitions provided by other generic
nptl headers.
Checked with run-built-tests=no against hppa-linux-gnu.
Change-Id: I95f55d5b7b7ae528c81cd2394d57ce92398189bf
Adds the __libpthread_version_placeholder symbol with the same version
of nanosleep/__nanosleep that was removed by 79a547b162 and that
is not provided by other symbols.
The generic version is straightforward. For Hurd, its nanosleep
implementation is moved to clock_nanosleep with adjustments from
generic unix implementation.
The generic clock_nanosleep unix version is also removed since
it calls nanosleep.
Checked on x86_64-linux-gnu and powerpc64le-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Checked on x86_64-linux-gnu and powerpc64le-linux-gnu. I also checked
the libpthread.so .gnu.version_d entries for every ABI affected and
all of them contains the required versions (including for architectures
which exports __nanosleep with a different version).
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Nothing defines CALL_PSELECT6 in the current tree, so remove it.
Tested with:
- make PARALLELMFLAGS="-j8" && make xcheck PARALLELMFLAGS="-j8" (x86_64)
- scripts/build-many-glibcs.py
The hppa architecture requires strict alignment for loads and stores.
As a result, the minimum stack alignment that will work is 8 bytes.
This patch adjusts __clone() to align the stack argument passed to it.
It also adjusts slightly some formatting.
This fixes the nptl/tst-tls1 test.
This patch provides new __futimens64 explicit 64 bit function for
setting access and modification time of file (by using its file descriptor).
Moreover, a 32 bit version - __futimens has been refactored to internally use
__futimens64.
The __futimens is now supposed to be used on systems still supporting
32 bit time (__TIMESIZE != 64) - hence the necessary conversions to 64 bit
struct __timespec64.
When pointer to struct __timespec64 is NULL - the file access and modification
time is set to the current one (by the kernel) and no conversions from struct
timespec to __timespec64 are performed.
The __futimens64 reuses __utimensat64_helper defined for __utimensat64.
The test procedure for __futimens64 is the same as for __utimensat64 conversion
patch.
This patch provides new __utimensat64 explicit 64 bit function for
setting access and modification time of a file. Moreover, a 32 bit version
- __utimensat has been refactored to internally use __utimensat64.
The __utimensat is now supposed to be used on systems still supporting
32 bit time (__TIMESIZE != 64) - hence the necessary conversions to 64 bit
struct __timespec64.
When pointer to struct __timespec64 is NULL - the file access and modification
time is set to the current one and no conversions from struct timespec to
__timespec64 are performed.
The new utimensat_time64 syscall available from Linux 5.1+ has been used,
when applicable.
The new helper function - __utimensat64_helper - has been introduced to
facilitate code re-usage on function providing futimens syscall handling.
The Linux kernel checks if passed tv_nsec value overflows, so there is no
need to repeat it in glibc.
When utimensat syscall on systems supporting 32 bit time ABI is used,
the check is performed if passed data (which may have 64 bit tv_sec) fits
into 32 bit range.
Build tests:
- The code has been tested on x86_64/x86 (native compilation):
make PARALLELMFLAGS="-j8" && make xcheck PARALLELMFLAGS="-j8"
- The glibc has been build tested (make PARALLELMFLAGS="-j8") for
x86 (i386), x86_64-x32, and armv7
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
- Use of cross-test-ssh.sh for ARM (armv7):
make PARALLELMFLAGS="-j8" test-wrapper='./cross-test-ssh.sh root@192.168.7.2' xcheck
Linux kernel, headers and minimal kernel version for glibc build test
matrix:
- Linux v5.1 (with utimensat_time64) and glibc build with v5.1 as
minimal kernel version (--enable-kernel="5.1.0")
The __ASSUME_TIME64_SYSCALLS flag defined.
- Linux v5.1 and default minimal kernel version
The __ASSUME_TIME64_SYSCALLS not defined, but kernel supports utimensat_time64
syscall.
- Linux v4.19 (no utimensat_time64 support) with default minimal kernel
version for contemporary glibc
This kernel doesn't support utimensat_time64 syscall, so the fallback
to utimensat is tested.
The above tests were performed with Y2038 redirection applied as well as
without (so the __TIMESIZE != 64 execution path is checked as well).
No regressions were observed.
Introduce pthread_clockjoin_np as a version of pthread_timedjoin_np that
accepts a clockid_t parameter to indicate which clock the timeout should be
measured against. This mirrors the recently-added POSIX-proposed "clock"
wait functions.
Checked on x86_64-linux-gnu.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To help y2038 work avoid duplicate all the logic of nanosleep on
non cancellable version, the patch replace it with a new futex
operation, lll_timedwait. The changes are:
- Add a expected value for __lll_clocklock_wait, so it can be used
to wait for generic values.
- Remove its internal atomic operation and move the logic to
__lll_clocklock. It makes __lll_clocklock_wait even more generic
and __lll_clocklock slight faster on fast-path (since it won't
require a function call anymore).
- Add lll_timedwait, which uses __lll_clocklock_wait, to replace both
__pause_nocancel and __nanosleep_nocancel.
It also allows remove the sparc32 __lll_clocklock_wait implementation
(since it is similar to the generic one).
Checked on x86_64-linux-gnu, sparcv9-linux-gnu, and i686-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
NPTL is already Linux specific, there is no need to parametrize low
level lock futex operations and add a sysdep Linux specific
implementation. This patch moves the relevant Linux code to nptl one.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
NPTL is already Linux specific, there is no need to parametrize futex
operations and add a sysdep Linux specific implementation. This patch
moves the relevant Linux code to nptl one.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Also make the public prototype of gettimeofday declare its second
argument with type "void *" unconditionally, consistent with POSIX.
It is also consistent with POSIX.
Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu.
Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Consolidate generic gettimeofday implementation to use clock_gettime.
Linux ports that still provide gettimeofday through vDSO are not
changed.
Remove sysdeps/unix/clock_gettime.c, which implemented clock_gettime
using gettimeofday; new OS ports must provide a real implementation of
clock_gettime.
Rename sysdeps/mach/gettimeofday.c to sysdeps/mach/clock_gettime.c and
convert into an implementation of clock_gettime. It only supports
CLOCK_REALTIME; Mach does not appear to have any support for monotonic
clocks. It uses __host_get_time, which provides at best microsecond
resolution. Hurd is currently using sysdeps/posix/clock_getres.c for
clock_getres; its output for CLOCK_REALTIME is based on
sysconf (_SC_CLK_TCK), and I do not know whether that gives the
correct result.
Unlike settimeofday, there are no known uses of gettimeofday's
vestigial "get time zone" feature that are not bugs. (The per-process
timezone support in localtime and friends is unrelated, and the
programs that set the kernel's offset between the hardware clock and
UTC do not need to read it back.) Therefore, this feature is dummied
out. Henceforth, if gettimeofday's "struct timezone" argument is not
NULL, it will write zeroes to both fields. Any program that is
actually looking at this data will thus think it is running in UTC,
which is probably more correct than whatever it was doing before.
[__]gettimeofday no longer has any internal callers, so we can now
remove its internal prototype and PLT bypass aliases. The
__gettimeofday@GLIBC_2.0 export remains, in case it is used by any
third-party code.
It also allows to simplify the arch-specific implementation on x86 and
powerpc to remove the hack to disable the internal route to non iFUNC
variant for internal symbol.
This patch also fixes a missing optimization on aarch64, powerpc, and
x86 where the code used on static build do not use the vDSO.
Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu.
Co-authored-by: Zack Weinberg <zackw@panix.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
timespec_get is the same function as clock_gettime, with an obnoxious
coating of NIH painted on it by the ISO C committee. In addition to
the rename, it takes its arguments in a different order, it returns 0
on *failure* or a positive number on *success*, and it requires that
all of its TIME_* constants be positive. This last means we cannot
directly reuse the existing CLOCK_* constants for it, because
those have been allocated starting with CLOCK_REALTIME = 0 on all
existing platforms.
This patch simply promotes the sysdeps/posix implementation to
universal, and removes the Linux-specific implementation, whose
apparent reason for existing was to cut out one function call's worth
of overhead.
Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
ftime is an obsolete variation on gettimeofday, offering only
millisecond time resolution; it was probably a system call in ooold
versions of BSD Unix. For historic reasons, we had three
implementations of it. These are all consolidated into time/ftime.c,
and then the function is deprecated.
For some reason, the implementation of ftime in terms of gettimeofday
was rounding rather than truncating microseconds to milliseconds. In
all the other places where we use a higher-resolution time function to
implement a lower-resolution one, we truncate. ftime is changed to
match, just for tidiness' sake.
Like gettimeofday, ftime tries to report the time zone, and using that
information is always a bug. This patch dummies out the reported
timezone information; the timezone and dstflag fields of the
returned "struct timeb" will always be zero.
Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, and powerpc-linux-gnu.
Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
As for gettimeofday, time will be implemented based on clock_gettime
on all platforms and internal code should use clock_gettime
directly. In addition to removing a layer of indirection, this will
allow us to remove the PLT-bypass gunk for gettimeofday.
The changed code always assumes __clock_gettime (CLOCK_REALTIME)
or __clock_gettime (CLOCK_REALTIME_COARSE) (for Linux case) cannot
fail, using the same rationale for gettimeofday change. And internal
helper was added (time_now).
Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, and powerpc-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Change the default implementation of time to call clock_gettime,
to align with new Linux ports that are expected to only implement
__NR_clock_gettime. Arch-specific implementation that either call
the time vDSO or route to gettimeofday vDSO are not removed.
Also for Linux, CLOCK_REALTIME_COARSE is used instead of generic
CLOCK_REALTIME clockid. This takes less CPU time and its behavior
better matches what the current glibc does.
Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu.
Co-authored-by: Zack Weinberg <zackw@panix.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Unconditionally, on all ports, use clock_settime to implement
settimeofday. Remove sysdeps/unix/clock_settime.c, which implemented
clock_settime by calling settimeofday; new OS ports must henceforth
provide a real implementation of clock_settime.
Hurd had a real implementation of settimeofday but not of
clock_settime; this patch converts it into an implementation of
clock_settime. It only supports CLOCK_REALTIME and microsecond
resolution; Hurd/Mach does not appear to have any support for
finer-resolution clocks.
The vestigial "set time zone" feature of settimeofday complicates the
generic settimeofday implementation a little. The only remaining uses
of this feature that aren't just bugs, are using it to inform the
Linux kernel of the offset between the hardware clock and UTC, on
systems where the hardware clock doesn't run in UTC (usually because
of dual-booting with Windows). There currently isn't any other way to
do this. However, the callers that do this call settimeofday with
_only_ the timezone argument non-NULL. Therefore, glibc's new
behavior is: callers of settimeofday must supply one and only one of
the two arguments. If both arguments are non-NULL, or both arguments
are NULL, the call fails and sets errno to EINVAL.
When only the timeval argument is supplied, settimeofday calls
__clock_settime(CLOCK_REALTIME), same as stime.
When only the timezone argument is supplied, settimeofday calls a new
internal function called __settimezone. On Linux, only, this function
will pass the timezone structure to the settimeofday system call. On
all other operating systems, and on Linux architectures that don't
define __NR_settimeofday, __settimezone is a stub that always sets
errno to ENOSYS and returns -1.
The settimeoday syscall is enabled on Linux by the flag
COMPAT_32BIT_TIME, which is an option to either 32-bits ABIs or COMPAT
builds (defined usually by 64-bit kernels that want to support 32-bit
ABIs, such as x86). The idea to future 64-bit time_t only ABIs
is to not provide settimeofday syscall.
The same semantics are implemented for Linux/Alpha's GLIBC_2.0 compat
symbol for settimeofday.
There are no longer any internal callers of __settimeofday, so the
internal prototype is removed.
Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Unconditionally, on all ports, use clock_settime to implement stime,
not settimeofday or a direct syscall. Then convert stime into a
compatibility symbol and remove its prototype from time.h.
Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Since gettimeofday will shortly be implemented in terms of
clock_gettime on all platforms, internal code should use clock_gettime
directly; in addition to removing a layer of indirection, this will
allow us to remove the PLT-bypass gunk for gettimeofday. (We can't
quite do that yet, but it'll be coming later in this patch series.)
In many cases, the changed code does fewer conversions.
The changed code always assumes __clock_gettime (CLOCK_REALTIME)
cannot fail. Most of the call sites were assuming gettimeofday could
not fail, but a few places were checking for errors. POSIX says
clock_gettime can only fail if the clock constant is invalid or
unsupported, and CLOCK_REALTIME is the one and only clock constant
that's required to be supported. For consistency I grepped the entire
source tree for any other places that checked for errors from
__clock_gettime (CLOCK_REALTIME), found one, and changed it too.
(For the record, POSIX also says gettimeofday can never fail.)
(It would be nice if we could declare that GNU systems will always
support CLOCK_MONOTONIC as well as CLOCK_REALTIME; there are several
places where we are using CLOCK_REALTIME where _MONOTONIC would be
more appropriate, and/or trying to use _MONOTONIC and then falling
back to _REALTIME. But the Hurd doesn't support CLOCK_MONOTONIC yet,
and it looks like adding it would involve substantial changes to
gnumach's internals and API. Oh well.)
A few Hurd-specific files were changed to use __host_get_time instead
of __clock_gettime, as this seemed tidier. We also assume this cannot
fail. Skimming the code in gnumach leads me to believe the only way
it could fail is if __mach_host_self also failed, and our
Hurd-specific code consistently assumes that can't happen, so I'm
going with that.
With the exception of support/support_test_main.c, test cases are not
modified, mainly because I didn't want to have to figure out which
test cases were testing gettimeofday specifically.
The definition of GETTIME in sysdeps/generic/memusage.h had a typo and
was not reading tv_sec at all. I fixed this. It appears nobody has been
generating malloc traces on a machine that doesn't have a superseding
definition.
There are a whole bunch of places where the code could be simplified
by factoring out timespec subtraction and/or comparison logic, but I
want to keep this patch as mechanical as possible.
Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Linux/Alpha has two versions of several system call wrappers that take
or return data of type "struct timeval" (possibly nested inside a
larger structure). The GLIBC_2.0 version is a compat symbol that
calls __NR_osf_foo or __NR_old_foo and uses a struct timeval with a
32-bit tv_sec field. The GLIBC_2.1 version is used for current code,
calls __NR_foo, and uses a struct timeval with a 64-bit tv_sec field.
This patch changes all of the compat symbols of this type to be
wrappers around their GLIBC_2.1 counterparts; the compatibility system
calls will no longer be used. It serves as a proposal for part of how
we do the transition to 64-bit time_t on systems that currently use
32-bit time_t:
* The patched glibc will NOT use system calls that involve 32-bit
time_t to implement its compatibility symbols. This will make both
our lives and the kernel maintainers' lives easier. The primary
argument I've seen against it is that the kernel could warn about
uses of the old system calls, helping people find old binaries that
need to be recompiled. I think there are several other ways we
could accomplish this, e.g. scripts to scan the filesystem for
binaries with references to the old symbol versions, or issuing
diagnostics ourselves.
* The compat symbols do NOT report failure after the Y2038 deadline.
An earlier revision of this patch had them return -1 and set errno
to EOVERFLOW, but Adhemerval pointed out that many of them have
already performed side effects at the point where we discover the
overflow, so that would break more than it fixes. Also, we don't
want people to be _checking_ for EOVERFLOW from these functions; we
want them to recompile with 64-bit time_t. So it's not actually
useful for them to report failure to the calling code.
* What they do do, when they encounter overflow, is saturate the
overflowed "struct timeval"(s): tv_sec is set to INT32_MAX and
tv_nsec is set to 999999. That means time stops advancing for
programs with 32-bit time_t when they reach the deadline. That's
obviously going to break stuff, but I think wrapping around is
probably going to break _more_ stuff. I'd be interested to hear
arguments against, if anyone has one.
The new header file tv32-compat.h is currently Alpha-specific but I
mean for it to be reused to aid in writing wrappers for all affected
architectures. I only put it in sysdeps/unix/sysv/linux/alpha for now
because I haven't checked whether the various "foo32" structures it
defines agree with the ABI for ports other than Linux/Alpha.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch provides new __clock_getres64 explicit 64 bit function for
getting the resolution (precision) of specified clock ID. Moreover, a
32 bit version - __clock_getres has been refactored to internally use
__clock_getres64.
The __clock_getres is now supposed to be used on systems still supporting
32 bit time (__TIMESIZE != 64) - hence the necessary conversion from 64 bit
struct __timespec64 to struct timespec.
The new clock_getres_time64 syscall available from Linux 5.1+ has been used,
when applicable.
On systems which are not supporting clock_getres_time64 (as their
clock_getres supports 64 bit time ABI) the vDSO syscall is attempted.
On the contrary the non-vDSO syscall is used for clock_getres_time64 as
up till now the kernel is not providing such interface.
No additional checks (i.e. if tv_nsec value overflow) are performed on
values returned via clock_getres{_time64} syscall, as it is assumed that
the Linux kernel will either return 0 and provide correct value or error.
The check for tv_sec being out of range on systems still supporting 32 bit
time (__TIMESIZE != 64) without Y2038 time support is also omitted as it is
_very_ unlikely that we would have a timer with resolution which exceeds 32
bit time_t range.
Build tests:
- The code has been tested on x86_64/x86 (native compilation):
make PARALLELMFLAGS="-j8" && make xcheck PARALLELMFLAGS="-j8"
- The glibc has been build tested (make PARALLELMFLAGS="-j8") for
x86 (i386), x86_64-x32, and armv7
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
- Use of cross-test-ssh.sh for ARM (armv7):
make PARALLELMFLAGS="-j8" test-wrapper='./cross-test-ssh.sh root@192.168.7.2' xcheck
Linux kernel, headers and minimal kernel version for glibc build test
matrix:
- Linux v5.1 (with clock_getres_time64) and glibc build with v5.1 as
minimal kernel version (--enable-kernel="5.1.0")
The __ASSUME_TIME64_SYSCALLS flag defined.
- Linux v5.1 and default minimal kernel version
The __ASSUME_TIME64_SYSCALLS not defined, but kernel supports
clock_getres_time64 syscall.
- Linux v4.19 (no clock_getres_time64 support) with default minimal kernel
version for contemporary glibc
This kernel doesn't support clock_getres_time64 syscall, so the fallback
to clock_getres is tested.
The above tests were performed with Y2038 redirection applied as well as
without (so the __TIMESIZE != 64 execution path is checked as well).
No regressions were observed.
The valid_nanoseconds () static inline function has been introduced to
check if nanoseconds value is in the correct range - greater or equal to
zero and less than 1000000000.
The explicit #include <time.h> has been added to files where it was
missing.
The __syscall_slong_t type for ns has been used to avoid issues on x32.
Tested with:
- scripts/build-many-glibcs.py
- make PARALLELMFLAGS="-j12" && make PARALLELMFLAGS="-j12" xcheck on x86_64
Add a new macro __STATFS_MATCHES_STATFS64 that specifies if fsblkcnt_t
matches fsblkcnt64_t and if fsfilcnt_t matches fsfilcnt64_t.
As we don't have the padding we also need to update the overflow checker
to not access the undefined members.
On a 32-bit platform with a 64-bit ino_t type (__INO_T_MATCHES_INO64_T
defined) we want to update the stat struct to remove the padding as it
isn't required. As we don't have the padding we also need to update the
overflow checker to not access the undefined members.
As an svc invocation does not clobber any user space registers
despite of the return value r2 and it does not need a special
stack frame. This patch gets rid of the extra frame.
We just have to save and restore r6 and r7 as those are
preserved across function calls.
The rewritten clock_settime code (which now supports 64 bit time on systems
with __WORDSIZE == 32) for Linux now relies on the
__ASSUME_TIME64_SYSCALLS flag set.
Lets explicitly include the header file where it is defined to avoid
any indirect inclusion (which may pose some unwanted API definitions).
Tested with scripts/build-many-glibcs.py script.
This is in preparation for changes in the dynamic linker so that
pread() is used instead of lseek()+read().
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Linux 5.1 adds missing SySV IPC syscalls to the syscall table for
remanining one that still uses the ipc syscall on glibc (m68k, mips-o32,
powerpc, s390, sh, and sparc32). However the newly added direct ipc
syscall are different than the old ones:
1. They do not expect IPC_64, meaning __IPC_64 should be set to zero
when new syscalls are used. And new syscalls can not be used
for compat functions like __old_semctl (to emulated old sysvipc it
requires to use the old __NR_ipc syscall without __IPC_64).
Thus IPC_64 is redefined for newer kernels on affected ABIs.
2. semtimedop and semop does not exist on 32-bit ABIs (only
semtimedop_time64 is supplied). The provided syscall wrappers only
uses the wire-up syscall if __NR_semtimedop and __NR_semop are
also defined.
Checked on x86_64-linux-gnu and i686-linux-gnu on both a 4.15 kernel
configure with default options and sysvipc tests on a 5.3.0 kernel with
--enable-kernel=5.1.
Tested-by: Paul A. Clarke <pc@us.ibm.com>
All nptl targets have these signal definitions nowadays. This
changes also replaces the nptl-generic version of pthread_sigmask
with the Linux version.
Tested on x86_64-linux-gnu and i686-linux-gnu. Built with
build-many-glibcs.py.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Besides semop being a subset of semtimedop, new 32-bit architectures
on Linux are not expected to provide the syscall (only the 64-bit time
semtimedop).
Also, Linux 5.1 only wired-up semtimedop for the 64-bit architectures
that missed it (powerpc, s390, and sparc). This simplifies the code
to support it.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
This patch refactor the internal sysvipc in two main points:
1. Add a new __ASSUME_SYSVIPC_DEFAULT_IPC_64 to infer the __IPC_64
value to be used along either the multiplexed __NR_ipc or wired-up
syscall. The defaut value assumed for __IPC_64 is also changed
from 0x100 to 0x0, aligning with Linux generic UAPI. The idea
is to simplify the Linux 5.1 wire-up for sysvipc syscalls for
some 32-bit ABIs (which expectes __IPC_64 being 0x0) and simplify
new ports (which will no longer need to add ipc_priv.h).
2. It also removes some duplicated internal definition used on compat
sysvipc symbols defined at ipc_priv.h (more specifically the
__old_ipc_perm, SEMCTL_ARG_ADDRESS, MSGRCV_ARGS, and
SEMTIMEDOP_IPC_ARGS). The idea is also to make it simpler to enable
the new wire-up sysvipc syscall provided by Linux v5.1.
There is no semantic change expected on any port. Checked with a build
against all affected ABIs.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
