Due to the built-in tables, __NR_set_robust_list is always defined
(although it may not be available at run time).
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.
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).
Checked on i686-linux-gnu.
[1] https://gcc.gnu.org/ml/gcc/2004-05/msg00030.html
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>
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).
Checked against a i686-gnu (run-built-tests=no)
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>
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.
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.
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.
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.
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>
