math: Remove inline math tests

With mathinline removal there is no need to keep building and testing
inline math tests.

The gen-libm-tests.py support to generate ULP_I_* is removed and all
libm-test-ulps files are updated to longer have the
i{float,double,ldouble} entries.  The support for no-test-inline is
also removed from both gen-auto-libm-tests and the
auto-libm-test-out-* were regenerated.

Checked on x86_64-linux-gnu and i686-linux-gnu.

Remove __LIBC_INTERNAL_MATH_INLINES

With m68k mathinline.h removal the flag is not used anymore.

Checked with a m68k-linux-gnu build/check.

math: Remove mathinline

With m68k bits moved to internal headers, no architectures export
additional optimizations on mathinline.

m68k: Remove mathinline.h

This is similar to x86 (da75c1b180f9355a) and powerpc (32ea72999693b98e)
mathinline.h removal.  The required macros to build the fpu routines
are moved to mathimpl.h, while the inline optimization macros for
atan, tanh, rint, log1p, significand, trunc, floor, ceil, isinf,
finite, scalbn, isnan, scalbln, nearbyint, lrint, and sincos are removed.

The gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94204 was
created to track builtin support.

Checked with a build against m68k-linux-gnu, resulting binaries
are similar with and without the patch.

oc_FR locale: Fix spelling of Thursday (bug 25639)

As reported by a native speaker:

Thursday: "dijóus" -> "dijòus" (also confirmed by CLDR)

x86: Remove ARCH_CET_LEGACY_BITMAP [BZ #25397]

Since legacy bitmap doesn't cover jitted code generated by legacy JIT
engine, it isn't very useful.  This patch removes ARCH_CET_LEGACY_BITMAP
and treats indirect branch tracking similar to shadow stack by removing
legacy bitmap support.

Tested on CET Linux/x86-64 and non-CET Linux/x86-64.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>

Fix build with GCC 10 when long double = double.

On platforms where long double has the same ABI as double, glibc
defines long double functions as aliases for the corresponding double
functions.  The declarations of those functions in <math.h> are
disabled to avoid problems with aliases having incompatible types, but
GCC 10 now gives errors for incompatible types when the long double
function is known to GCC as a built-in function, not just when there
is an incompatible header declaration.

This patch fixes those errors by using appropriate
-fno-builtin-<function> options to compile the double functions.  The
list of CFLAGS-* settings is an appropriately adapted version of that
in sysdeps/ieee754/ldbl-opt/Makefile used there for building nldbl-*.c
files; in particular, the options are used even if GCC does not
currently have a built-in function of a given function, so that adding
such a built-in function in future will not break the glibc build.
Thus, various of the CFLAGS-* settings are only for future-proofing
and may not currently be needed (and it's possible some could be
irrelevant for other reasons).

Tested with build-many-glibcs.py for arm-linux-gnueabi (compilers and
glibcs builds), where it fixes the build that previously failed.

nscd/cachedumper.c : fix whitespace

Fix nscd/cachedumper.c compile errors

manual: Fix inconsistent declaration of wcsrchr [BZ #24655]

Reviewed-by: DJ Delorie <dj@redhat.com>

nscd: add cache dumper

parse_tunables: Fix typo in comment

ldconfig: trace origin paths with -v

With this patch, -v turns on a "from" trace for each directory
searched, that tells you WHY that directory is being searched -
is it a builtin, from the command line, or from some config file?

test-container: print errno when execvp fails

I'm debugging a situation where lots of tests using test-container fail
and it's possible knowing errno would help understand why.

Reviewed-by: DJ Delorie <dj@redhat.com>

[AArch64] Improve integer memcpy

Further optimize integer memcpy.  Small cases now include copies up
to 32 bytes.  64-128 byte copies are split into two cases to improve
performance of 64-96 byte copies.  Comments have been rewritten.

Add NEWS entry for CVE-2020-10029 (bug 25487)

gcc PR 89877: miscompilation due to missing cc clobber in longlong.h macros

simple test such as below was failing.

| void main(int argc, char *argv[])
| {
|    size_t total_time = 115424;                       // expected 115.424
|    double secs = (double)total_time/(double)1000;
|    printf("%s %d %lf\n", "secs", total_time, secs);  // prints 113.504
|    printf("%d\n", (size_t)secs);
| }

The printf eventually called into glibc stdlib/divrem.c:__mpn_divrem()
which uses the __arc__ specific inline asm macros from longlong.h which
were causing miscompilation.

include/
2019-03-28  Vineet Gupta <vgupta@synopsys.com>

PR 89877

* longlong.h [__arc__] (add_ssaaaa): Add cc clobber
(sub_ddmmss): Likewise.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

mips: Fix wrong INTERNAL_SYSCALL_ERROR_P check from bc2eb9321e

Checked on mips64-linux-gnu.

elf: Fix wrong indentation from commit eb447b7b4b

y2038: linux: Provide __futimesat64 implementation

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.

y2038: linux: Provide __lutimes64 implementation

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.

y2038: linux: Provide __futimes64 implementation

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.

y2038: fix: Add missing libc_hidden_def for __futimens64

The libc_hidden_def () declaration for __futimens64 function was missing,
so it is added in this patch.

sparc: Move sigreturn stub to assembly

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

ldbl-128ibm: Let long double files have specific compiler flags

Soon, powerpc64le will need to provide extra compiler flags to the long
double files in order to continue to build using the IBM 128-bit
extended floating point type as long double.

ldbl-128ibm-compat: Add tests for IBM long double functions

This patch creates test-ibm128* tests from the long double function tests.
In order to explicitly test IBM long double functions -mabi=ibmlongdouble is
added to CFLAGS.

Likewise, update the test headers to correct choose ULPs when redirects
are enabled.

Co-authored-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Co-authored-by: Paul E. Murphy <murphyp@linux.vnet.ibm.com>

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>

arm: Fix softp-fp Implies (BZ #25635)

The commit "arm: Split BE/LE abilist"
(1673ba87fefe019c834c09d33673d1d453ea698d) changed the soft-fp order for
ARM selection when __SOFTFP__ is defined by the compiler.

On 2.30 the sysdeps order is:

2.30
sysdeps/unix/sysv/linux/arm
sysdeps/arm/nptl
sysdeps/unix/sysv/linux
sysdeps/nptl
sysdeps/pthread
sysdeps/gnu
sysdeps/unix/inet
sysdeps/unix/sysv
sysdeps/unix/arm
sysdeps/unix
sysdeps/posix
sysdeps/arm/nofpu
sysdeps/ieee754/soft-fp
sysdeps/arm
sysdeps/wordsize-32
sysdeps/ieee754/flt-32
sysdeps/ieee754/dbl-64
sysdeps/ieee754
sysdeps/generic

While on master is:

sysdeps/unix/sysv/linux/arm/le
sysdeps/unix/sysv/linux/arm
sysdeps/arm/nptl
sysdeps/unix/sysv/linux
sysdeps/nptl
sysdeps/pthread
sysdeps/gnu
sysdeps/unix/inet
sysdeps/unix/sysv
sysdeps/unix/arm
sysdeps/unix
sysdeps/posix
sysdeps/arm/le
sysdeps/arm
sysdeps/wordsize-32
sysdeps/ieee754/flt-32
sysdeps/ieee754/dbl-64
sysdeps/arm/nofpu
sysdeps/ieee754/soft-fp
sysdeps/ieee754
sysdeps/generic

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.

With this patch the order is now:

sysdeps/unix/sysv/linux/arm/le
sysdeps/unix/sysv/linux/arm
sysdeps/arm/nptl
sysdeps/unix/sysv/linux
sysdeps/nptlsysdeps/pthread
sysdeps/gnu
sysdeps/unix/inet
sysdeps/unix/sysv
sysdeps/unix/arm
sysdeps/unix
sysdeps/posix
sysdeps/arm/le/nofpu
sysdeps/arm/nofpu
sysdeps/ieee754/soft-fp
sysdeps/arm/le
sysdeps/arm
sysdeps/wordsize-32
sysdeps/ieee754/flt-32
sysdeps/ieee754/dbl-64
sysdeps/ieee754
sysdeps/generic

Checked on arm-linux-gnuaebi.

Remove reference of --without-fp on configure

linux/sysipc: Include linux/posix_types.h for __kernel_mode_t

The posix_types.h (where __kernel_mode_t is defined) is included
implicitly, which might not happen on older kernels.

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.

Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

linux: Clear mode_t padding bits (BZ#25623)

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.

linux: Remove aarch64 ipc_priv.h

The aarch64 ipc_priv.h is superflous since
__ASSUME_SYSVIPC_DEFAULT_IPC_64 is now defined as default.

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.

Linux: Use AT_FDCWD in utime, utimes when calling utimensat

0 is a valid descriptor without any special meaning.

Reviewed-by: Lukasz Majewski <lukma@denx.de>

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.

manual: Fix wrong declaration of wcschr [BZ #24654]

manual: Fix typo in parse_printf_format example [BZ #24638]

Update translations

Incorporated updated translations from translationproject.org

Convert Python scripts to Python 3

Change all of the #! lines in Python scripts that are called from
Makefiles to reference /usr/bin/python3.

All of the scripts called from Makefiles are already run with Python 3,
so let's make sure they are explicitly using Python 3 if called
manually.

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.

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.

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>

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.

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>

y2038: Introduce struct __utimbuf64 - new internal glibc type

This type is a glibc's "internal" type to store file's access and modification
times in __time64_t rather than __time_t, which makes it Y2038-proof.

Build tests:
./src/scripts/build-many-glibcs.py glibcs

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

microblaze: vfork is always available

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>

m68k: getpagesize syscall number is always available

Due to the built-in tables, __NR_getpagesize is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: epoll_pwait syscall number is always available

Due to the built-in tables, __NR_epoll_pwait is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

x86_64: Do not define __NR_semtimedop in <sysdep.h>

The definition is always available from the built-in system call table.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

ia64: Do not define __NR_semtimedop in <sysdep.h>

The definition is always available from the built-in system call table.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: open_by_handle_at syscall number is always available

Due to the built-in tables, __NR_open_by_handle_at is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: set_robust_list syscall number is always available

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>

Linux: pciconfig_iobase syscall number is always available on alpha

Due to the built-in tables, __NR_pciconfig_iobase is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: getdents64 syscall number is always available on MIPS

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>

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.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: exit_group syscall number is always available

Due to the built-in tables, __NR_exit_group is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: set_tid_address syscall number is always available

Due to the built-in tables, __NR_set_tid_address is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: pkey_mprotect syscall number is always available

Due to the built-in tables, __NR_pkey_mprotect is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: rt_sigqueueinfo syscall number is always available

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>

Linux: getrandom syscall number is always available

Due to the built-in tables, __NR_getrandom is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: Clean up preadv, pwritev system call names

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: 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.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: sigaltstack syscall number is always available

Due to the built-in tables, __NR_sigaltstack is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: sched_getaffinity syscall number is always available

Due to the built-in tables, __NR_sched_getaffinity is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: sched_setaffinity syscall number is always available

Due to the built-in tables, __NR_sched_setaffinity is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: statx syscall number is always available

Due to the built-in tables, __NR_statx is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

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.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: mlock2 syscall number is always available

Due to the built-in tables, __NR_mlock2 is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: copy_file_range syscall number is always available

Due to the built-in tables, __NR_copy_file_range is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: renameat2 syscall number is always available

Due to the built-in tables, __NR_renameat2 is always defined.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

build-many-glibcs.py: Add list-compilers, list-glibcs commands

These commands are helpful for scripting the distribution of
build-many-glibcs.py runs across multiple builders.

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.

Fixed typo in run_command_array() in support/shell-container.c

https://sourceware.org/bugzilla/show_bug.cgi?id=23991

Add missing libc_hidden_def for __utimensat64

elf: Add elf/check-wx-segment, a test for the presence of WX segments

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.

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).

Checked on i686-linux-gnu.

[1] https://gcc.gnu.org/ml/gcc/2004-05/msg00030.html

ldbl-128ibm-compat: link tst-ldbl-efgcvt against loader too

This also requires the linker workaround to ensure everything links
correctly.  See comment in sysdeps/powerpc/powerpc64/le/Makefile
for details.

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.

ldbl-128ibm-compat: Provide nexttoward functions

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: Provide a significand implementation

Reuse the template in order to provide the global symbol
__significandieee128.

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.

posix: Remove posix waitid

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)

posix: Refactor tst-waitid (BZ #14666)

The main changes are:

  - 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.

Checked on x86_64-linux-gnu and i686-linux-gnu.

support: Add support_process_state_wait

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.

Checked on x86_64-linux-gnu.

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.

Fixes commit 3a0ecccb599a6b1ad4b149dc569c0080e92d057b ("ld.so: Do not
export free/calloc/malloc/realloc functions [BZ #25486]").

powerpc: Refactor fenvinline.h

This patch refactor fenviline.h replaces some statements for
builtins.

Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>

nss_nis: Use NSS_DECLARE_MODULE_FUNCTIONS

This commit removes the minor optimization based on strong aliases
because it loses type safety.

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.)

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>

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.

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.

nios2: Fix Linux kABI for syscall return

From the type introduced at 861be5fd66.

Fix use-after-free in glob when expanding ~user (bug 25414)

The value of `end_name' points into the value of `dirname', thus don't
deallocate the latter before the last use of the former.

nptl: Move pthread_setschedparam implementation into libc

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>

nptl: Move pthread_getschedparam implementation into libc

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>

Add hidden prototypes for __sched_getparam, __sched_getscheduler

This will enable them to be used in libc.so without PLTs.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

nptl: Move pthread_cond_init implementation into libc

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>