| Age | Commit message (Collapse) | Author |
|---|
|
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).
|
|
|
|
Since both wait and waitpid are implemented on top of wait4. It fixes
nptl/tst-cancel{x}{4,5,7}.
Checked on alpha-linux-gnu.
|
|
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>
|
|
Rename ifunc for kunpeng to kunpeng920, and modify the corresponding
function files including IS_KUNPENG920 judgement.
Checked on aarch64-linux-gnu.
|
|
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>
|
|
The generic one calls wait4.
Checked on x86_64-linux-gnu.
|
|
This also consolidate all waitpid implementations.
Checked on x86_64-linux-gnu.
|
|
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.
|
|
Checked on x86_64-linux-gnu and powerpc64le-linux-gnu.
|
|
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.
|
|
* include/sys/random.h (__getrandom): Add hidden prototype.
* stdlib/getrandom.c (getrandom): Rename to hidden definition __getrandom.
Add weak alias.
* sysdeps/mach/hurd/getrandom.c (getrandom): Likewise.
* sysdeps/unix/sysv/linux/getrandom.c (getrandom): Likewise.
* sysdeps/mach/hurd/getentropy.c (getentropy): Use __getrandom instead of
getrandom.
|
|
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 (4f4bb489e0dd).
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 06be6368da16104be5) 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
|
|
(CVE-2019-19126) [BZ #25204]
The problem was introduced in glibc 2.23, in commit
b9eb92ab05204df772eb4929eccd018637c9f3e9
("Add Prefer_MAP_32BIT_EXEC to map executable pages with MAP_32BIT").
|
|
Change-Id: Ic6ec48f75f3a0576d3121befd04531382c92afb4
|
|
Change-Id: If5df5b05d15f0418af821a9ac8cc0fad53437b10
|
|
This patch fixes the time64 support (added by 2e44b10b42d) 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.
|
