powerpc: Fix feraiseexcept and feclearexcept macros
A recent change to fenvinline.h modified the check if __e is a
a power of 2 inside feraiseexcept and feclearexcept macros. It
introduced the use of the powerof2 macro but also removed the
if statement checking whether __e != 0 before issuing an mtfsb*
instruction. This is problematic because powerof2 (0) evaluates
to 1 and without the removed if __e is allowed to be 0 when
__builtin_clz is called. In that case the value 32 is passed
to __MTFSB*, which is invalid.
This commit uses __builtin_popcount instead of powerof2 to fix this
issue and avoid the extra check for __e != 0. This was the approach
used by the initial versions of that previous patch.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
The commit "arm: Split BE/LE abilist"
(1673ba87fefe019c834c09d33673d1d453ea698d) changed the soft-fp order for
ARM selection when __SOFTFP__ is defined by the compiler.
It make the build select some routines (fadd, fdiv, fmul, fsub, and fma)
on ieee754/flt-32 and ieee754/dbl-64 that requires fenv support to be
correctly rounded which in turns lead to math failures since the
__SOFTFP__ does not have fenv support.
Fangrui Song [Wed, 5 Feb 2020 05:55:44 +0000 (21:55 -0800)]
Improve IFUNC check [BZ #25506]
GNU ld's RISCV port does not support IFUNC. ld -no-pie produces no
relocation and the test passed incorrectly. Be more rigid by testing
IRELATIVE explicitly.
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.
Florian Weimer [Thu, 5 Mar 2020 12:27:53 +0000 (13:27 +0100)]
Linux: Use __fstatat64 in fchmodat implementation
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.
Stefan Liebler [Thu, 5 Mar 2020 11:52:19 +0000 (12:52 +0100)]
S390: Remove backchain-based fallback and use generic backtrace.c.
After recent discussions:
- "[PATCH] s390: Remove backchain-based fallback from backtrace"
https://www.sourceware.org/ml/libc-alpha/2020-02/msg00287.html
- "Re: [PATCH 07/11] s390: Implement backtrace on top of <unwind-link.h>"
https://www.sourceware.org/ml/libc-alpha/2020-02/msg00637.html
We've checked and decided to remove the backchain:
We don't know of any environments without libgcc. Thus the backchain
unwinder is not used. If somebody builds with -mbackchain and without
fasynchronous-unwind-tables and has libgcc installed, then the
libgcc unwinder is called but not the backchain-based fallback.
This step allows to get rid of the s390x specific backtrace.c files at all.
Furthermore the now used debug/backtrace.c version has some more
advantages:
- Free all resources if necessary. (libc_freeres_fn)
- Remove NULL address above _start.
- Check whether we make any progress while getting addresses.
Florian Weimer [Tue, 3 Mar 2020 14:41:49 +0000 (15:41 +0100)]
alpha: Do not build with -fpic
The combination of GCC 10 and binutils 2.35 (both unreleased) is no
longer able to link the dynamic linker, due to a GP16 relocation
overflow error:
glibc/alpha-linux-gnu/elf/librtld.os: in function `calloc': glibc/elf/../include/rtld-malloc.h:44:(.text+0xd98): relocation truncated to fit: GPREL16 against symbol `__rtld_calloc' defined in .data.rel.ro section in glibc/alpha-linux-gnu/elf/librtld.os
glibc/alpha-linux-gnu/elf/librtld.os: in function `malloc': glibc/elf/../include/rtld-malloc.h:56:(.text+0x2978): relocation truncated to fit: GPREL16 against symbol `__rtld_malloc' defined in .data.rel.ro section in glibc/alpha-linux-gnu/elf/librtld.os
This is arguably a linker bug; the object files and their section size
requirements look reasonable enough.
Using -fPIC (the default) works around this issue.
Lukasz Majewski [Thu, 6 Feb 2020 12:25:35 +0000 (13:25 +0100)]
y2038: linux: Provide __utime64 implementation
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.
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.
Lukasz Majewski [Thu, 6 Feb 2020 11:34:48 +0000 (12:34 +0100)]
y2038: linux: Provide __utimes64 implementation
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.
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.
Florian Weimer [Tue, 3 Mar 2020 11:18:22 +0000 (12:18 +0100)]
Linux: Clean up preadv2, pwritev2 system call names
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.
Florian Weimer [Sun, 9 Feb 2020 15:07:00 +0000 (16:07 +0100)]
Linux: Clean up pread64/pwrite64 system call names
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.
Florian Weimer [Tue, 3 Mar 2020 11:11:49 +0000 (12:11 +0100)]
Linux: mq_* syscall numbers are always available
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.
Florian Weimer [Fri, 28 Feb 2020 11:32:28 +0000 (12:32 +0100)]
build-many-glibcs.py: Add --shallow option
The history is not used by build-many-glibcs.py itself.
--replace-sources deletes an existing source tree before switching
the version. But some users prefer to have the full history
available, therefore make shallow clones optional with the --shallow
option.
i386: Use comdat instead of .gnu.linkonce for i386 setup pic register (BZ #20543)
GCC has moved from using .gnu.linkonce for i386 setup pic register with
minimum current version (as for binutils minimum binutils that support
comdat).
Trying to pinpoint when binutils has added comdat support for i686, it
seems it was around 2004 [1]. I also checking with some ancient
binutils older than 2.16 I see:
test.o: In function `__x86.get_pc_thunk.bx':
test.o(.text.__x86.get_pc_thunk.bx+0x0): multiple definition of `__x86.get_pc_thunk.bx'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/crti.o(.gnu.linkonce.t.__x86.get_pc_thunk.bx+0x0): first defined here
Which seems that such version can not handle either comdat at all or
a mix of linkonce and comdat. For binutils 2.16.1 I am getting a
different issue trying to link a binary with and more recent
ctri.o (unrecognized relocation (0x2b) in section `.init', which is
R_386_GOT32X and old binutils won't generate it anyway).
So I think that either unlikely someone will use an older binutils than
the one used to glibc and even this scenario may fail with some issue
as the R_386_GOT32X. Also, 2.16.1 is quite old and not really supported
(glibc itself required 2.25).
Paul E. Murphy [Fri, 7 Feb 2020 20:06:53 +0000 (14:06 -0600)]
ldbl-128ibm-compat: enforce ibm128 on compat tests
For lack of a more comprehensive solution, tack on the ibm128 ABI
compiler options for the totalorder{,mag}l compat tests which exist
prior to enabling this feature.
The functions in the nexttoward family are special, in the sense that
they always have a long double argument, regardless of their suffix
(i.e.: nexttowardf and nexttoward have a long double argument, besides
the float and double arguments).
On top of that, they are also special because nexttoward functions are
not part of the _FloatN API, hence __nexttowardf128 do not exist.
This patch adds 4 new function implementations for the new long double
format:
__nexttoward_to_ieee128
__nexttowardf_to_ieee128
__nexttowardieee128 (as an alias to __nextafterieee128)
Likewise, rename "long double" "_Float128" in shared ldbl-128
files to ensure correct type is used irrespective of ABI
switches.
Thank you to those who helped out with this patch:
Co-Authored-By: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
ldbl-128ibm-compat: Redirect complex math functions
The API doesn't change, i.e. compilers using a long double format compatible
with the IEEE 128-bit extended precision format are redirected from *l
functions to __*ieee128 symbols using the same mechanism already
used with -mlong-double-64 for complex math functions.
ldbl-128ibm-compat: Redirect long double functions to f128/ieee128 functions
Modify the headers to redirect long double functions to global __*f128
symbols or to __*ieee128 otherwise.
Most of the functions in math.h benefit from the infrastructure already
available for __LDBL_COMPAT. The only exceptions are nexttowardf and
nexttoward that need especial treatment.
Both math/bits/mathcalls-helper-functions.h and math/bits/mathcalls.h
were modified in order to provide alternative redirection destinations
that are essential to support functions that should not be redirected to
the same name pattern of the rest of the functions, i.e.: __fpclassify,
__signbit, __iseqsig, __issignaling, isinf, finite and isnan, which will
be redirected to __*f128 instead of __*ieee128 used for the rest.
The POSIX waitid implementation is problematic in some ways:
- It emulates using waitpid, which default implementation calls
wait4 and wait4 returns ENOSYS as default.
- Also by using waitpid it does not allod support the WNOWAIT,
WEXITED, WSTOPPED, or WCONTINUED flag. With current POSIX
specification the flags are no longer marked as optional.
Also due BZ#23091 Hurd still uses the implementation, so it is moved
to as a Hurd arch-specific folder (with some minor cleanups).
- Adapt to libsupport.
- Synchronize the signal handler using atomics.
- Replace waitpid by waitid calls.
- Use support_process_state_wait to wait for child state.
- Add tests for P_PGID and P_ALL.
- Use sigwaitinfo instead of global state set by the signal handler.
It allows parent process to wait for child state using a polling
strategy over procfs on Linux. The polling is used over ptrace to
avoid the need to handle signals on the target pid and to handle some
system specific limitation (such as YAMA).
The polling has some limitations, such as resource consumption due
the procfs read in a loop and the lack of synchronization after the
state is obtained.
The interface idea is to simplify some sleep synchronization waitid
tests and is to reduce timeouts by replacing arbitrary waits.
malloc/tst-mallocfork2: Kill lingering process for unexpected failures
If the test fails due some unexpected failure after the children
creation, either in the signal handler by calling abort or in the main
loop; the created children might not be killed properly.
This patches fixes it by:
* Avoid aborting in the signal handler by setting a flag that
an error has occured and add a check in the main loop.
* Add a atexit handler to handle kill child processes.
Florian Weimer [Wed, 26 Feb 2020 14:58:23 +0000 (15:58 +0100)]
elf: Apply attribute_relro to pointers in elf/dl-minimal.c
The present code leaves the function pointers unprotected, but moves
some of the static functions into .data.rel.ro instead. This causes
the linker to produce an allocatable, executable, writable section
and eventually an RWX load segment. Not only do we really do not
want that, it also breaks valgrind because valgrind does not load
debuginfo from the mmap interceptor if all it sees are RX and RWX
mappings.
Florian Weimer [Mon, 24 Feb 2020 10:50:24 +0000 (11:50 +0100)]
csu: Use ELF constructor instead of _init in libc.so
On !ELF_INITFINI architectures, _init is no longer called by the
dynamic linker. We can use an ELF constructor instead because the
constructor order does not matter. (The other constructors are used
to set up libio vtable bypasses and do not depend on this
initialization routine.)
Paul E. Murphy [Fri, 7 Feb 2020 20:07:01 +0000 (14:07 -0600)]
ldbl-128ibm: make ieee754.h work with IEEE 128 long double
Instead of attempting something more creative, just copy
the small struct from ldbl-128 and enable it when IEEE
long double is present, and update the ibm long double
variant if supported.
Likewise, provide a shadow copy of math_ldbl.h to prevent
the ibm128 specific long double header from poisoning
unrelated files due to it's usage in math_private.h.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Paul E. Murphy [Fri, 7 Feb 2020 20:06:41 +0000 (14:06 -0600)]
ldbl-128ibm-compat: fixup subdir location of several funcs
We want to ensure that if a second file is built to support
ieee128 long double, we built its companion implementation
with ibm128 long double. The shared object versions of these
files build correctly because the aliasing is sufficiently
complex to prevent the redirects from applying when defining
them.
However, this does not prevent the static object variants
from becoming quietly broken due to redirects. This is
intentionally avoided by marking such objects to be built
with -mabi=ibmlongdouble.
Shuffle the misplaced routines to build against the subdir
which defines the needed symbols.
Paul E. Murphy [Fri, 7 Feb 2020 20:06:35 +0000 (14:06 -0600)]
ldbl-128ibm-compat: enforce correct abi flags on internal file
A number of utility files and helper objects should also be
explicitly configured to build with the ibm128 ABI to prevent
gremlins when enabling IEEE long double.
ldbl-128ibm-compat: Provide ieee128 symbols to narrow functions
Move the narrow math aliasing macros into a new sysdep header file
math-narrow-alias-float128.h. Then, provide an override header
to supply the necessary changes to supply the *ieee128 aliases of
these symbols.
This adds ieee128 aliases for faddl, fdivl, fmull, fsubl, daddl, ddivl,
dmull, dsubl.
Undefine redirections after long double definition on __LDBL_COMPAT [BZ #23294]
After defining the long double redirections to double, __MATHDECL_1 has
to be redefined to its previous state in order to avoid redirecting all
subsequent types.
Block all signals on timer_create thread (BZ#10815)
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).
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>
Lukasz Majewski [Mon, 27 Jan 2020 14:37:07 +0000 (15:37 +0100)]
y2038: linux: Provide __gettimeofday64 implementation
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).
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]
Florian Weimer [Tue, 18 Feb 2020 16:52:27 +0000 (17:52 +0100)]
Linux: Work around kernel bugs in chmod on /proc/self/fd paths [BZ #14578]
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.
Florian Weimer [Tue, 18 Feb 2020 13:42:41 +0000 (14:42 +0100)]
Introduce <elf-initfini.h> and ELF_INITFINI for all architectures
This supersedes the init_array sysdeps directory. It allows us to
check for ELF_INITFINI in both C and assembler code, and skip DT_INIT
and DT_FINI processing completely on newer architectures.
A new header file is needed because <dl-machine.h> is incompatible
with assembler code. <sysdep.h> is compatible with assembler code,
but it cannot be included in all assembler files because on some
architectures, it redefines register names, and some assembler files
conflict with that.
<elf-initfini.h> is replicated for legacy architectures which need
DT_INIT/DT_FINI support. New architectures follow the generic default
and disable it.
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. */
Florian Weimer [Tue, 18 Feb 2020 12:44:48 +0000 (13:44 +0100)]
Move implementation of <file_change_detection.h> into a C file
file_change_detection_for_stat partially initialize
struct file_change_detection in some cases, when the size member
alone determines the outcome of all comparisons. This results
in maybe-uninitialized compiler warnings in case of sufficiently
aggressive inlining.
Once the implementation is moved into a separate C file, this kind
of inlining is no longer possible, so the compiler warnings are gone.
Prepare redirections for IEEE long double on powerpc64le
All functions that have a format string, which can consume a long double
argument, must have one version for each long double format supported on
a platform. On powerpc64le, these functions currently have two versions
(i.e.: long double with the same format as double, and long double with
IBM Extended Precision format). Support for a third long double format
option (i.e. long double with IEEE long double format) is being prepared
and all the aforementioned functions now have a third version (not yet
exported on the master branch, but the code is in).
For these functions to get selected (during build time), references to
them in user programs (or dependent libraries) must get redirected to
the aforementioned new versions of the functions. This patch installs
the header magic required to perform such redirections.
Notice, however, that since the redirections only happen when
__LONG_DOUBLE_USES_FLOAT128 is set to 1, and no platform (including
powerpc64le) currently does it, no redirections actually happen.
Redirections and the exporting of the new functions will happen at the
same time (when powerpc64le adds ldbl-128ibm-compat to their Implies.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> Reviewed-by: Paul E. Murphy <murphyp@linux.vnet.ibm.com>
Florian Weimer [Mon, 17 Feb 2020 10:30:17 +0000 (11:30 +0100)]
stdlib: Reduce namespace pollution in <inttypes.h>
The namespace pollution results in conform test failures if the tests
are run __USE_EXTERN_INLINES defined (e.g., when configuring with
CC="gcc -O3" CXX="g++ -O3").
projects / thirdparty / glibc.git / log
