This is a preparatory patch to enable building a _Float128
variant to ease reuse when building a _Float128 variant to
alias this long double only symbol.
Notably, stubs are added where missing to the native _Float128
sysdep dir to prevent building these newly templated variants
created inside the build directories.
Also noteworthy are the changes around LIBM_SVID_COMPAT. These
changes are not intuitive. The templated version is only
enabled when !LIBM_SVID_COMPAT, and the compat version is
predicated entirely on LIBM_SVID_COMPAT. Thus, exactly one is
stubbed out entirely when building. The nldbl scalb compat
files are updated to account for this.
Likewise, fixup the reuse of m68k's e_scalb{f,l}.c to include
it's override of e_scalb.c. Otherwise, the search path finds
the templated copy in the build directory. This could be
futher simplified by providing an overridden template, but I
lack the hardware to verify.
Joseph Myers [Fri, 14 Feb 2020 14:16:25 +0000 (14:16 +0000)]
Adjust thresholds in Bessel function implementations (bug 14469).
A recent discussion in bug 14469 notes that a threshold in float
Bessel function implementations, used to determine when to use a
simpler implementation approach, results in substantially inaccurate
results.
As I discussed in
<https://sourceware.org/ml/libc-alpha/2013-03/msg00345.html>, a
heuristic argument suggests 2^(S+P) as the right order of magnitude
for a suitable threshold, where S is the number of significand bits in
the floating-point type and P is the number of significant bits in the
representation of the floating-point type, and the float and ldbl-96
implementations use thresholds that are too small. Some threshold
does need using, there or elsewhere in the implementation, to avoid
spurious underflow and overflow for large arguments.
This patch sets the thresholds in the affected implementations to more
heuristically justifiable values. Results will still be inaccurate
close to zeroes of the functions (thus this patch does *not* fix any
of the bugs for Bessel function inaccuracy); fixing that would require
a different implementation approach, likely along the lines described
in <http://www.cl.cam.ac.uk/~jrh13/papers/bessel.ps.gz>.
So the justification for a change such as this would be statistical
rather than based on particular tests that had excessive errors and no
longer do so (no doubt such tests could be found, but would probably
be too fragile to add to the testsuite, as liable to give large errors
again from very small implementation changes or even from compiler
changes). See
<https://sourceware.org/ml/libc-alpha/2020-02/msg00638.html> for such
statistics of the resulting improvements for float functions.
Florian Weimer [Tue, 21 Jan 2020 16:38:15 +0000 (17:38 +0100)]
resolv: Fix ABA race in /etc/resolv.conf change detection [BZ #25420]
__resolv_conf_get_current should only record the initial file
change data if after verifying that file just read matches the
original measurement. Fixes commit aef16cc8a4c670036d45590877
("resolv: Automatically reload a changed /etc/resolv.conf file
[BZ #984]").
Florian Weimer [Tue, 21 Jan 2020 16:11:01 +0000 (17:11 +0100)]
resolv: Fix file handle leak in __resolv_conf_load [BZ #25429]
res_vinit_1 did not close the stream on errors, only on success.
This change moves closing the stream to __resolv_conf_load, for both
the success and error cases.
Joseph Myers [Thu, 13 Feb 2020 21:59:59 +0000 (21:59 +0000)]
Add STATX_ATTR_VERITY from Linux 5.5 to bits/statx-generic.h.
This patch adds the new STATX_ATTR_VERITY macro from Linux 5.5 to
glibc's bits/statx-generic.h. (This only does anything if glibc is
being used with old kernel headers.)
By undef strong_alias on alpha implementation, the
default_symbol_version macro becomes an empty macro on static build.
It fixes the issue introduced at c953219420.
Checked on alpha-linux-gnu with a 'make check run-built-tests=no'.
Joseph Myers [Wed, 12 Feb 2020 23:31:56 +0000 (23:31 +0000)]
Avoid ldbl-96 stack corruption from range reduction of pseudo-zero (bug 25487).
Bug 25487 reports stack corruption in ldbl-96 sinl on a pseudo-zero
argument (an representation where all the significand bits, including
the explicit high bit, are zero, but the exponent is not zero, which
is not a valid representation for the long double type).
Although this is not a valid long double representation, existing
practice in this area (see bug 4586, originally marked invalid but
subsequently fixed) is that we still seek to avoid invalid memory
accesses as a result, in case of programs that treat arbitrary binary
data as long double representations, although the invalid
representations of the ldbl-96 format do not need to be consistently
handled the same as any particular valid representation.
This patch makes the range reduction detect pseudo-zero and unnormal
representations that would otherwise go to __kernel_rem_pio2, and
returns a NaN for them instead of continuing with the range reduction
process. (Pseudo-zero and unnormal representations whose unbiased
exponent is less than -1 have already been safely returned from the
function before this point without going through the rest of range
reduction.) Pseudo-zero representations would previously result in
the value passed to __kernel_rem_pio2 being all-zero, which is
definitely unsafe; unnormal representations would previously result in
a value passed whose high bit is zero, which might well be unsafe
since that is not a form of input expected by __kernel_rem_pio2.
Matheus Castanho [Wed, 12 Feb 2020 16:07:32 +0000 (13:07 -0300)]
sunrpc: Properly clean up if tst-udp-timeout fails
The macro TEST_VERIFY_EXIT is used several times on
sunrpc/tst-udp-timeout to exit the test if a condition evaluates to
false. The side effect is that the code to terminate the RPC server
process is not executed when the program calls exit, so that
sub-process stays alive.
This commit registers a clean up function with atexit to kill the
server process before exiting the main program.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
David Kilroy [Wed, 12 Feb 2020 17:31:17 +0000 (14:31 -0300)]
elf: avoid stack allocation in dl_open_worker
As the sort was removed, there's no need to keep a separate map of
links. Instead, when relocating objects iterate over l_initfini
directly.
This allows us to remove the loop copying l_initfini elements into
map. We still need a loop to identify the first and last elements that
need relocation.
David Kilroy [Wed, 12 Feb 2020 17:28:15 +0000 (14:28 -0300)]
elf: Allow dlopen of filter object to work [BZ #16272]
There are two fixes that are needed to be able to dlopen filter
objects. First _dl_map_object_deps cannot assume that map will be at
the beginning of l_searchlist.r_list[], as filtees are inserted before
map. Secondly dl_open_worker needs to ensure that filtees get
relocated.
In _dl_map_object_deps:
* avoiding removing relocation dependencies of map by setting
l_reserved to 0 and otherwise processing the rest of the search
list.
* ensure that map remains at the beginning of l_initfini - the list
of things that need initialisation (and destruction). Do this by
splitting the copy up. This may not be required, but matches the
initialization order without dlopen.
Modify dl_open_worker to relocate the objects in new->l_inifini.
new->l_initfini is constructed in _dl_map_object_deps, and lists the
objects that need initialization and destruction. Originally the list
of objects in new->l_next are relocated. All of these objects should
also be included in new->l_initfini (both lists are populated with
dependencies in _dl_map_object_deps). We can't use new->l_prev to pick
up filtees, as during a recursive dlopen from an interposed malloc
call, l->prev can contain objects that are not ready for relocation.
Add tests to verify that symbols resolve to the filtee implementation
when auxiliary and filter objects are used, both as a normal link and
when dlopen'd.
Joseph Myers [Wed, 12 Feb 2020 13:37:16 +0000 (13:37 +0000)]
Rename RWF_WRITE_LIFE_NOT_SET to RWH_WRITE_LIFE_NOT_SET following Linux 5.5.
Linux 5.5 renames RWF_WRITE_LIFE_NOT_SET to RWH_WRITE_LIFE_NOT_SET,
with the old name kept as an alias. This patch makes the
corresponding change in glibc.
Stefan Liebler [Wed, 12 Feb 2020 08:10:56 +0000 (09:10 +0100)]
S390: Fix non-ascii character in fenv.h.
The comment "isn't" contained a non-ascii character which leads to
an error if compiled with -finput-charset=ascii:
error: failure to convert ascii to UTF-8
This is observable in GCC testsuite:
FAIL: 17_intro/headers/c++1998/charset.cc (test for excess errors)
FAIL: 17_intro/headers/c++2011/charset.cc (test for excess errors)
FAIL: 17_intro/headers/c++2014/charset.cc (test for excess errors)
FAIL: 17_intro/headers/c++2017/charset.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/charset.cc (test for excess errors)
The code started out with bits form resolv/resolv_conf.c, but it
was enhanced to deal with directories and FIFOs in a more predictable
manner. A test case is included as well.
This will be used to implement the /etc/resolv.conf change detection.
This currently lives in a header file only. Once there are multiple
users, the implementations should be moved into C files.
Fangrui Song [Wed, 12 Feb 2020 06:10:19 +0000 (01:10 -0500)]
elf.h: Add R_RISCV_IRELATIVE
The number has been officially assigned by
https://github.com/riscv/riscv-elf-psabi-doc/pull/131
https://github.com/riscv/riscv-elf-psabi-doc/commit/d21ca40a7f56812a15e97450b7bc1599c0d35b82
Samuel Thibault [Mon, 10 Feb 2020 22:06:33 +0000 (23:06 +0100)]
hurd: Add __pthread_spin_wait and use it
900778283ac3 ("htl: make pthread_spin_lock really spin") made
pthread_spin_lock really spin and not block, but the current users of
__pthread_spin_lock were assuming that it blocks, i.e. they use it as a
lightweight mutex fitting in just one int.
Joseph Myers [Mon, 10 Feb 2020 22:17:59 +0000 (22:17 +0000)]
Use --disable-gdbserver in build-many-glibcs.py.
Now that binutils-gdb has gdbserver at top level, an extra
--disable-gdbserver configure option is needed when configuring
binutils from a git checkout to avoid it also building gdbserver
unnecessarily (although fairly harmlessly). This patch updates the
options used in build-many-glibcs.py accordingly (although this might
end up not being needed depending on what happens regarding whether
gdbserver gets built for host != target).
Tested with a build-many-glibcs.py compilers build for
aarch64-linux-gnu using binutils-gdb master.
Wilco Dijkstra [Mon, 10 Feb 2020 16:08:40 +0000 (16:08 +0000)]
Improve random memcpy benchmark
Improve the random memcpy benchmark. Double the number of copies and
increase the memory sizes tested to 512KB. Add a more detailed
distribution of memcpy alignment and sizes up to 4096 based on SPEC2017
traces.
Samuel Thibault [Sun, 9 Feb 2020 16:34:26 +0000 (16:34 +0000)]
htl: Do not put spin_lock inlines in public headers
They were not getting used anyway.
Also do not make libsupport use them, it would make tests using it have
to be made to link against libmachuser for gsync_wait.
Florian Weimer [Sun, 9 Feb 2020 10:01:39 +0000 (11:01 +0100)]
x86: Remove <bits/select.h> and use the generic version
Particularly on CPUs without ERMS, the string instructions are slow,
so it is unclear whether this architecture-specific implementation is
in fact an optimization.
Florian Weimer [Sun, 9 Feb 2020 10:51:08 +0000 (11:51 +0100)]
Linux: Add io/tst-o_path-locks test
The O_PATH-based fchmodat emulation will rely on the fact that closing
an O_PATH descriptor never releases POSIX advisory locks, so this
commit adds a test case for this behavior.
Florian Weimer [Fri, 7 Feb 2020 17:48:04 +0000 (18:48 +0100)]
resolv: Fix CNAME chaining in resolv/tst-resolv-ai_idn-common.c
The second CNAME record optionally generated by the response function
used the question name, not the redirected name from the first CNAME.
This breaks the chain and results in failures of these IDNA tests if
CNAME owner names are checked as expected (which the current
implementation does not do).
Lukasz Majewski [Thu, 16 Jan 2020 22:14:27 +0000 (23:14 +0100)]
y2038: linux: Provide __settimeofday64 implementation
This patch provides new __settimeofday64 explicit 64 bit function for setting
64 bit time in the kernel (by internally calling __clock_settime64).
Moreover, a 32 bit version - __settimeofday has been refactored to internally
use __settimeofday64.
The __settimeofday 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 __timespec64.
Internally the settimeofday uses __settimeofday64. This patch is necessary
for having architectures with __WORDSIZE == 32 Y2038 safe.
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 __settimeofday64 and __settimeofday.
Lukasz Majewski [Thu, 16 Jan 2020 22:44:59 +0000 (23:44 +0100)]
y2038: Provide conversion helpers for struct __timeval64
Those functions allow easy conversion between Y2038 safe, glibc internal
struct __timeval64 and other time related data structures (like struct timeval
or struct __timespec64).
Lukasz Majewski [Fri, 17 Jan 2020 14:29:56 +0000 (15:29 +0100)]
y2038: alpha: Rename valid_timeval_to_timeval64 to valid_timeval32_to_timeval
Without this patch the naming convention for functions to convert
struct timeval32 to struct timeval (which supports 64 bit time on Alpha) was
a bit misleading. The name 'valid_timeval_to_timeval64' suggest conversion
of struct timeval to struct __timeval64 (as in ./include/time.h).
As on alpha the struct timeval supports 64 bit time it seems more readable
to emphasis struct timeval32 in the conversion function name.
Hence the helper function naming change to 'valid_timeval32_to_timeval'.
Lukasz Majewski [Thu, 16 Jan 2020 22:40:51 +0000 (23:40 +0100)]
y2038: Introduce struct __timeval64 - new internal glibc type
This type is a glibc's "internal" type similar to struct timeval but
whose tv_sec field is a __time64_t rather than a time_t, which makes it
Y2038-proof. This struct is NOT supposed to be passed to the kernel -
instead it shall be converted to struct __timespec64 and clock_[sg]ettime
syscalls shall be used (which are now Y2038 safe).
Lukasz Majewski [Sat, 25 Jan 2020 21:33:41 +0000 (22:33 +0100)]
y2038: Define __suseconds64_t type to be used with struct __timeval64
The __suseconds64_t type is supposed to be the 64 bit type across all
architectures.
It would be mostly used internally in the glibc - however, when passed to
Linux kernel (very unlikely), if necessary, it shall be converted to 32
bit type (i.e. __suseconds_t)
Joseph Myers [Fri, 7 Feb 2020 13:55:29 +0000 (13:55 +0000)]
Update kernel version to 5.5 in tst-mman-consts.py.
This patch updates the kernel version in the test tst-mman-consts.py
to 5.5. (There are no new constants covered by this test in 5.5 that
need any other header changes.)
Joseph Myers [Fri, 7 Feb 2020 13:54:58 +0000 (13:54 +0000)]
Update syscall lists for Linux 5.5.
Linux 5.5 has no new syscalls to add to syscall-names.list, but it
does newly enable the clone3 syscall for AArch64. This patch updates
the kernel version listed in syscall-names.list and regenerates the
AArch64 arch-syscall.h.