sysv/alpha: Use generic __timeval32 and helpers

Now there is a generic __timeval32 and helpers we can use them for Alpha
instead of the Alpha specific ones.

Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

linux: Use long time_t for wait4/getrusage

The Linux kernel expects rusage to use a 32-bit time_t, even on archs
with a 64-bit time_t (like RV32). To address this let's convert
rusage to/from 32-bit and 64-bit to ensure the kernel always gets
a 32-bit time_t.

While we are converting these functions let's also convert them to be
the y2038 safe versions. This means there is a *64 function that is
called by a backwards compatible wrapper.

Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

resource: Add a __rusage64 struct

Add a __rusage64 struct which always uses a 64-bit time_t.

Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

linux: Use long time_t __getitimer/__setitimer

The Linux kernel expects itimerval to use a 32-bit time_t, even on archs
with a 64-bit time_t (like RV32). To address this let's convert
itimerval to/from 32-bit and 64-bit to ensure the kernel always gets
a 32-bit time_t.

While we are converting these functions let's also convert them to be
the y2038 safe versions. This means there is a *64 function that is
called by a backwards compatible wrapper.

Tested-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

sysv: Define __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64

On y2038 safe 32-bit systems the Linux kernel expects itimerval
and rusage to use a 32-bit time_t, even though the other time_t's
are 64-bit. There are currently no plans to make 64-bit time_t versions
of these structs.

There are also other occurrences where the time passed to the kernel via
timeval doesn't match the wordsize.

To handle these cases let's define a new macro
__KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64. This macro specifies if the
kernel's old_timeval matches the new timeval64. This should be 1 for
64-bit architectures except for Alpha's osf syscalls. The define should
be 0 for 32-bit architectures and Alpha's osf syscalls.

Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

math: Add inputs that yield larger errors for float type (x86_64)

The corner cases included were generated using exhaustive search
for all float/binary32 values on x86_64 (comparing to MPFR for
correct rounding to nearest).

For the j0/j1/y0 functions, only cases with ulp error <= 9 were
included.

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

Fix alignment bug in Safe-Linking

Alignment checks should be performed on the user's buffer and NOT
on the mchunkptr as was done before. This caused bugs in 32 bit
versions, because: 2*sizeof(t) != MALLOC_ALIGNMENT.

As the tcache works on users' buffers it uses the aligned_OK()
check, and the rest work on mchunkptr and therefore check using
misaligned_chunk().

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

Typo fixes and CR cleanup in Safe-Linking

Removed unneeded '\' chars from end of lines and fixed some
indentation issues that were introduced in the original
Safe-Linking patch.

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

Use Linux 5.6 and GMP 6.2.0 in build-many-glibcs.py.

This patch makes build-many-glibcs.py use the current versions of
Linux (5.6) and GMP (6.2.0).

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).

Add new file missed in previous hppa commit.

powerpc: Add support for fmaf128() in hardware

Adds a POWER9 version of fmaf128 that uses the xsmaddqp
instruction.

Co-authored-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Fix data race in setting function descriptors during lazy binding on hppa.

This addresses an issue that is present mainly on SMP machines running
threaded code.  In a typical indirect call or PLT import stub, the
target address is loaded first.  Then the global pointer is loaded into
the PIC register in the delay slot of a branch to the target address.
During lazy binding, the target address is a trampoline which transfers
to _dl_runtime_resolve().

_dl_runtime_resolve() uses the relocation offset stored in the global
pointer and the linkage map stored in the trampoline to find the
relocation.  Then, the function descriptor is updated.

In a multi-threaded application, it is possible for the global pointer
to be updated between the load of the target address and the global
pointer.  When this happens, the relocation offset has been replaced
by the new global pointer.  The function pointer has probably been
updated as well but there is no way to find the address of the function
descriptor and to transfer to the target.  So, _dl_runtime_resolve()
typically crashes.

HP-UX addressed this problem by adding an extra pc-relative branch to
the trampoline.  The descriptor is initially setup to point to the
branch.  The branch then transfers to the trampoline.  This allowed
the trampoline code to figure out which descriptor was being used
without any modification to user code.  I didn't use this approach
as it is more complex and changes function pointer canonicalization.

The order of loading the target address and global pointer in
indirect calls was not consistent with the order used in import stubs.
In particular, $$dyncall and some inline versions of it loaded the
global pointer first.  This was inconsistent with the global pointer
being updated first in dl-machine.h.  Assuming the accesses are
ordered, we want elf_machine_fixup_plt() to store the global pointer
first and calls to load it last.  Then, the global pointer will be
correct when the target function is entered.

However, just to make things more fun, HP added support for
out-of-order execution of accesses in PA 2.0.  The accesses used by
calls are weakly ordered. So, it's possibly under some circumstances
that a function might be entered with the wrong global pointer.
However, HP uses weakly ordered accesses in 64-bit HP-UX, so I assume
that loading the global pointer in the delay slot of the branch must
work consistently.

The basic fix for the race is a combination of modifying user code to
preserve the address of the function descriptor in register %r22 and
setting the least-significant bit in the relocation offset.  The
latter was suggested by Carlos as a way to distinguish relocation
offsets from global pointer values.  Conventionally, %r22 is used
as the address of the function descriptor in calls to $$dyncall.
So, it wasn't hard to preserve the address in %r22.

I have updated gcc trunk and gcc-9 branch to not clobber %r22 in
$$dyncall and inline indirect calls.  I have also modified the import
stubs in binutils trunk and the 2.33 branch to preserve %r22.  This
required making the stubs one instruction longer but we save one
relocation.  I also modified binutils to align the .plt section on
a 8-byte boundary.  This allows descriptors to be updated atomically
with a floting-point store.

With these changes, _dl_runtime_resolve() can fallback to an alternate
mechanism to find the relocation offset when it has been clobbered.
There's just one additional instruction in the fast path. I tested
the fallback function, _dl_fix_reloc_arg(), by changing the branch to
always use the fallback.  Old code still runs as it did before.

Fixes bug 23296.

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

sparc: Move __fenv_{ld,st}fsr to fenv-private.h

These should not be exported on installed headers.

Checked on sparc64-linux-gnu and sparcv9-linux-gnu.

x86: Remove feraiseexcept optimization

Similar to fenvinline.h removal, this kind of optimization is better
implemented by the compiler.  Also newer code avoid setting exceptions
directly (for instance the code to make new logf, log2f and powf
implementatation to now support SVID compat).

The BZ#94194 [1] the corresponding GCC bug for adding replacements
for these on x86.

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

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94194

math: Remove fenvinline.h

Similar to string2.h (18b10de7ce) and string3.h (09a596cc2c) this
patch removes the fenvinline.h on all architectures.  Currently
only powerpc implements some optimizations.  This kind of optimization
is better implemented by the compiler (which handles the architecture
ISA transparently).

Also, for the specific optimized powerpc implementation the code is
becoming convoluted and these micro-optimization are hardly wildly
used, even more being a possible hotspot in realword cases
(non-default rounding are used only on specific cases and exception
handling are done most likely only on errors path).  Only x86
implements similar optimization (on fenv.h) also indicates that
these should no be on libc.

The math/test-fenv already covers all math/test-fenvinline tests,
so it is safe to remove it.

The powerpc fegetround optimization is moved to internal
fenv_libc.h.

The BZ#94193 [1] the corresponding GCC bug for adding replacements
for these on powerpc.

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

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94193

hurd: Make O_TRUNC update mtime/ctime

* hurd/lookup-retry.c (__hurd_file_name_lookup_retry): Call
__file_utimens after __file_set_size.

Add Safe-Linking to fastbins and tcache

Safe-Linking is a security mechanism that protects single-linked
lists (such as the fastbin and tcache) from being tampered by attackers.
The mechanism makes use of randomness from ASLR (mmap_base), and when
combined with chunk alignment integrity checks, it protects the "next"
pointers from being hijacked by an attacker.

While Safe-Unlinking protects double-linked lists (such as the small
bins), there wasn't any similar protection for attacks against
single-linked lists. This solution protects against 3 common attacks:
  * Partial pointer override: modifies the lower bytes (Little Endian)
  * Full pointer override: hijacks the pointer to an attacker's location
  * Unaligned chunks: pointing the list to an unaligned address

The design assumes an attacker doesn't know where the heap is located,
and uses the ASLR randomness to "sign" the single-linked pointers. We
mark the pointer as P and the location in which it is stored as L, and
the calculation will be:
  * PROTECT(P) := (L >> PAGE_SHIFT) XOR (P)
  * *L = PROTECT(P)

This way, the random bits from the address L (which start at the bit
in the PAGE_SHIFT position), will be merged with LSB of the stored
protected pointer. This protection layer prevents an attacker from
modifying the pointer into a controlled value.

An additional check that the chunks are MALLOC_ALIGNed adds an
important layer:
  * Attackers can't point to illegal (unaligned) memory addresses
  * Attackers must guess correctly the alignment bits

On standard 32 bit Linux machines, an attack will directly fail 7
out of 8 times, and on 64 bit machines it will fail 15 out of 16
times.

This proposed patch was benchmarked and it's effect on the overall
performance of the heap was negligible and couldn't be distinguished
from the default variance between tests on the vanilla version. A
similar protection was added to Chromium's version of TCMalloc
in 2012, and according to their documentation it had an overhead of
less than 2%.

Reviewed-by: DJ Delorie <dj@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Adhemerval Zacnella <adhemerval.zanella@linaro.org>

Add benchtests for roundeven and roundevenf.

This patch adds benchtests for the roundeven and roundevenf functions.
The inputs are copied from trunc-inputs.

time: Add a __itimerval64 struct

Add a __itimerval64 which always uses a 64-bit time_t.

Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

time: Add a timeval with a 32-bit tv_sec and tv_usec

On y2038 safe 32-bit systems the Linux kernel expects itimerval to
use a 32-bit time_t, even though the other time_t's are 64-bit. To
address this let's add a __timeval32 struct to be used internally.

Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

sysv/linux: Rename alpha functions to be alpha specific

These functions are alpha specifc, rename them to be clear.

Let's also rename the header file from tv32-compat.h to
alpha-tv32-compat.h. This is to avoid conflicts with the one we will
introduce later.

Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

ARC: add definitions to elf/elf.h

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

powerpc64: apply -mabi=ibmlongdouble to special files

Some of these files depend on the avoidance of using the various
register sets of POWER.  When enabling the IEEE 128 long double,
we must be sure to disable this ABI as some compilers will
refuse to compile if -mno-vsx and -mabi=ieeelongdouble are both
present.

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

powerpc64le: add -mno-gnu-attribute to *f128 objects and difftime

In practice, this flag should be applied globally, but it makes a good
sanity check to ensure ibm128 and ieee128 long double files are not
getting mismatched.  _Float128 files use no long double, thus are
always safe to use this option.

Similarly, when investigating the linker complaints, difftime
makes trivial, self contained, usage of long double, so thus it
is also explicitly marked as such.

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

Makeconfig: sandwich gnulib-tests between libc/ld linking of tests

This better resembles the default linking process with the gnulibs,
and also resolves the increasingly difficult to maintain
f128-loader-link usage on powerpc64le as some libgcc symbols are
dependent on those found in the loader (ld).

powerpc64le: Ensure correct ldouble compiler flags are used

Ensure the correct ldouble abi flags are applied to ibm128 files and
nldbl files.  Remove the IEEE options if used, and apply the flags
used to build ldouble files which are ibm128 abi.

nldbl tests are a little tricky.  To use the support, we must remove
all ldouble abi flags, and ensure -mlong-double-64 is used.

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

Fix tests which expose ldbl -> _Float128 redirects

The ldbl redirects for ieee128 have some jagged edges when
inspecting and manipulating symbols directly.

e.g asprintf is unconditionally redirected to __asprintfieee128
thus any tests relying on GCC's redirect behavior will encounter
problems if they inspect the symbol names too closely.

I've mitigated tests which expose the limitations of the
ldbl -> f128 redirects by giving them knowledge about the
redirected symbol names.

Hopefully there isn't much user code which depends on this
implementation specific behavior.

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

ldbl-128ibm-compat: PLT redirects for using ldbl redirects internally

Tweak the PLT bypass magic when building glibc with long double
redirects.  This is made more difficult by the fact we only get
one chance to redirect functions.  This happens via the public
headers.

There are roughly three classes of redirect we need to attend to
today:

 1. Simple redirects, redirected via cdef macro overrides and
    and new libc_hidden_ldbl_proto macro.
 2. Internal usage of internal API, e.g __snprintf, which has
    no direct analogue.  This is bypassed directly on case-by-
    case basis.
 3. Double redirects, e.g sscanf and related.  These require
    a heavier handed approach of macro renaming to existing
    symbols.

Most simple redirects are handled via 1.  Ideally, the libc_*
macro would live in libc-symbols.h, but in practice the macros
needed for it to do anything useful live in cdefs.h, so they
are defined in the local override.

Notably, the internal name of the asprintf generated for ieee ldbl
redirects is renamed to work with internal prefixed usage.

This resolves the local plt usage introduced when building glibc
with ldbl == ieee128 on ppc64le.

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

stdlib: Move tst-system to tests-container

Fix some issues with different shell and error messages.

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

support/shell-container.c: Add builtin kill

No options supported.

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

support/shell-container.c: Add builtin exit

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

support/shell-container.c: Return 127 if execve fails

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

Add NEWS entry for CVE-2020-1751 (bug 25423)

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

posix: Fix system error return value [BZ #25715]

It fixes 5fb7fc9635 when posix_spawn fails.

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

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

y2038: fix: Add missing libc_hidden_def attribute for some syscall wrappers

During the conversion to support 64 bit time on some architectures with
__WORDSIZE == 32 && __TIMESIZE != 64 the libc_hidden_def attribute for
eligible functions was by mistake omitted.

This patch fixes this issue and exports (and allows using) those
functions when Y2038 support is enabled in glibc.

Extended Char Intro: Use getwc in example (Bug 25626)

In the "Extended Char Intro" the example incorrectly uses a function
called wgetc which doesn't exist.  The example is corrected to use
getwc, which is correct for the use in this case.

Reported-by: Toomas Rosin <toomas@rosin.ee>

stdio: Add tests for printf multibyte convertion leak [BZ#25691]

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

stdio: Remove memory leak from multibyte convertion [BZ#25691]

This is an updated version of a previous patch [1] with the
following changes:

  - Use compiler overflow builtins on done_add_func function.
  - Define the scratch +utstring_converted_wide_string using
    CHAR_T.
  - Added a testcase and mention the bug report.

Both default and wide printf functions might leak memory when
manipulate multibyte characters conversion depending of the size
of the input (whether __libc_use_alloca trigger or not the fallback
heap allocation).

This patch fixes it by removing the extra memory allocation on
string formatting with conversion parts.

The testcase uses input argument size that trigger memory leaks
on unpatched code (using a scratch buffer the threashold to use
heap allocation is lower).

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

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
[1] https://sourceware.org/pipermail/libc-alpha/2017-June/082098.html

Add NEWS entry for CVE-2020-1752 (bug 25414)

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>