Zack Weinberg [Thu, 16 Feb 2017 22:31:42 +0000 (17:31 -0500)]
Add missing header files throughout the testsuite.
* crypt/md5.h: Test _LIBC with #if defined, not #if.
* dirent/opendir-tst1.c: Include sys/stat.h.
* dirent/tst-fdopendir.c: Include sys/stat.h.
* dirent/tst-fdopendir2.c: Include stdlib.h.
* dirent/tst-scandir.c: Include stdbool.h.
* elf/tst-auditmod1.c: Include link.h and stddef.h.
* elf/tst-tls15.c: Include stdlib.h.
* elf/tst-tls16.c: Include stdlib.h.
* elf/tst-tls17.c: Include stdlib.h.
* elf/tst-tls18.c: Include stdlib.h.
* iconv/tst-iconv6.c: Include endian.h.
* iconvdata/bug-iconv11.c: Include limits.h.
* io/test-utime.c: Include stdint.h.
* io/tst-faccessat.c: Include sys/stat.h.
* io/tst-fchmodat.c: Include sys/stat.h.
* io/tst-fchownat.c: Include sys/stat.h.
* io/tst-fstatat.c: Include sys/stat.h.
* io/tst-futimesat.c: Include sys/stat.h.
* io/tst-linkat.c: Include sys/stat.h.
* io/tst-mkdirat.c: Include sys/stat.h and stdbool.h.
* io/tst-mkfifoat.c: Include sys/stat.h and stdbool.h.
* io/tst-mknodat.c: Include sys/stat.h and stdbool.h.
* io/tst-openat.c: Include stdbool.h.
* io/tst-readlinkat.c: Include sys/stat.h.
* io/tst-renameat.c: Include sys/stat.h.
* io/tst-symlinkat.c: Include sys/stat.h.
* io/tst-unlinkat.c: Include stdbool.h.
* libio/bug-memstream1.c: Include stdlib.h.
* libio/bug-wmemstream1.c: Include stdlib.h.
* libio/tst-fwrite-error.c: Include stdlib.h.
* libio/tst-memstream1.c: Include stdlib.h.
* libio/tst-memstream2.c: Include stdlib.h.
* libio/tst-memstream3.c: Include stdlib.h.
* malloc/tst-interpose-aux.c: Include stdint.h.
* misc/tst-preadvwritev-common.c: Include sys/stat.h.
* nptl/tst-basic7.c: Include limits.h.
* nptl/tst-cancel25.c: Include pthread.h, not pthreadP.h.
* nptl/tst-cancel4.c: Include stddef.h, limits.h, and sys/stat.h.
* nptl/tst-cancel4_1.c: Include stddef.h.
* nptl/tst-cancel4_2.c: Include stddef.h.
* nptl/tst-cond16.c: Include limits.h.
Use sysconf(_SC_PAGESIZE) instead of __getpagesize.
* nptl/tst-cond18.c: Include limits.h.
Use sysconf(_SC_PAGESIZE) instead of __getpagesize.
* nptl/tst-cond4.c: Include stdint.h.
* nptl/tst-cond6.c: Include stdint.h.
* nptl/tst-stack2.c: Include limits.h.
* nptl/tst-stackguard1.c: Include stddef.h.
* nptl/tst-tls4.c: Include stdint.h. Don't include tls.h.
* nptl/tst-tls4moda.c: Include stddef.h.
Don't include stdio.h, unistd.h, or tls.h.
* nptl/tst-tls4modb.c: Include stddef.h.
Don't include stdio.h, unistd.h, or tls.h.
* nptl/tst-tls5.h: Include stddef.h. Don't include stdlib.h or tls.h.
* posix/tst-getaddrinfo2.c: Include stdio.h.
* posix/tst-getaddrinfo5.c: Include stdio.h.
* posix/tst-pathconf.c: Include sys/stat.h.
* posix/tst-posix_fadvise-common.c: Include stdint.h.
* posix/tst-preadwrite-common.c: Include sys/stat.h.
* posix/tst-regex.c: Include stdint.h.
Don't include spawn.h or spawn_int.h.
* posix/tst-regexloc.c: Don't include spawn.h or spawn_int.h.
* posix/tst-vfork3.c: Include sys/stat.h.
* resolv/tst-bug18665-tcp.c: Include stdlib.h.
* resolv/tst-res_hconf_reorder.c: Include stdlib.h.
* resolv/tst-resolv-search.c: Include stdlib.h.
* stdio-common/tst-fmemopen2.c: Include stdint.h.
* stdio-common/tst-vfprintf-width-prec.c: Include stdlib.h.
* stdlib/test-canon.c: Include sys/stat.h.
* stdlib/tst-tls-atexit.c: Include stdbool.h.
* string/test-memchr.c: Include stdint.h.
* string/tst-cmp.c: Include stdint.h.
* sysdeps/pthread/tst-timer.c: Include stdint.h.
* sysdeps/unix/sysv/linux/tst-sync_file_range.c: Include stdint.h.
* sysdeps/wordsize-64/tst-writev.c: Include limits.h and stdint.h.
* sysdeps/x86_64/fpu/math-tests-arch.h: Include cpu-features.h.
Don't include init-arch.h.
* sysdeps/x86_64/multiarch/test-multiarch.h: Include cpu-features.h.
Don't include init-arch.h.
* sysdeps/x86_64/tst-auditmod10b.c: Include link.h and stddef.h.
* sysdeps/x86_64/tst-auditmod3b.c: Include link.h and stddef.h.
* sysdeps/x86_64/tst-auditmod4b.c: Include link.h and stddef.h.
* sysdeps/x86_64/tst-auditmod5b.c: Include link.h and stddef.h.
* sysdeps/x86_64/tst-auditmod6b.c: Include link.h and stddef.h.
* sysdeps/x86_64/tst-auditmod6c.c: Include link.h and stddef.h.
* sysdeps/x86_64/tst-auditmod7b.c: Include link.h and stddef.h.
* time/clocktest.c: Include stdint.h.
* time/tst-posixtz.c: Include stdint.h.
* timezone/tst-timezone.c: Include stdint.h.
* string/strings.h: Do not suppress the file if string.h has
already been included.
(bcmp, bcopy, bzero, strcasecmp, strncasecmp): Add __nonnull
annotations.
(index, rindex): Define inline forwarders even if
__CORRECT_ISO_CPP_STRING_H_PROTO is defined.
(ffs): Use __attribute_const__.
(ffsl, ffsll): Declare here.
(strcasecmp_l, strncasecmp_l): Correct comments; these functions
have now been standardized.
Wilco Dijkstra [Wed, 15 Feb 2017 15:23:52 +0000 (15:23 +0000)]
Remove the str(n)cmp inlines from string/bits/string2.h. The strncmp
optimization seems unlikely to ever be useful, but if it occurs in
real code it should be added to GCC. Expanding strcmp of small strings
does appear useful (benchmarking shows it is 2-3x faster), so this would
be useful to implement in GCC (PR 78809).
Wilco Dijkstra [Wed, 15 Feb 2017 15:13:58 +0000 (15:13 +0000)]
The internal header include/string.h does not work in C++: it causes link errors
in several C++ debug tests when any of the functions it declares are called.
The best option would be to not use internal headers for tests (unless
explicitly needed). Add guards so that it is safe to use include/string.h from
C++.
Fix y0 and y1 exception handling for zero input [BZ #21134]
The Bessel functions of the second type (Yn) should raise the "divide
by zero" exception when input is zero (both positive and negative).
Current code gives the right output, but fails to set the exception.
This error is exposed for float, double, and long double when linking
with -lieee. Without this flag, the error is not exposed, because the
wrappers for these functions, which use __kernel_standard
functionality, set the exception as expected.
Tested for powerpc64le.
[BZ #21134]
* sysdeps/ieee754/dbl-64/e_j0.c (__ieee754_y0): Raise the
"divide by zero" exception when the input is zero.
* sysdeps/ieee754/dbl-64/e_j1.c (__ieee754_y1): Likewise.
* sysdeps/ieee754/flt-32/e_j0f.c (__ieee754_y0f): Likewise.
* sysdeps/ieee754/flt-32/e_j1f.c (__ieee754_y1f): Likewise.
* sysdeps/ieee754/ldbl-128/e_j0l.c (__ieee754_y0l): Likewise.
* sysdeps/ieee754/ldbl-128/e_j1l.c (__ieee754_y1l): Likewise.
Joseph Myers [Wed, 15 Feb 2017 01:13:15 +0000 (01:13 +0000)]
Move most libmvec test contents from .c to .h files.
The libmvec tests put substantive, architecture-specific contents in
.c files such as test-double-vlen4.c, so making those files
architecture-specific and causing issues for generating such files
automatically when splitting up tests by function.
This patch moves all the substantive contents to .h files, so the .c
files only include the .h file and then libm-test.c. This allows for
automatic generation of per-function .c files in future. The .h files
in turn #include or #include_next the architecture-independent file
and add the architecture-specific definitions to that. (Splitting by
function should in fact allow the TEST_VECTOR_* macros to be replaced
by sysdeps makefile information on which functions to test in each
case, removing the need for gen-libm-have-vector-test.sh as well as
removing the need for some of the architecture-specific headers.)
Tested for x86_64.
* sysdeps/x86_64/fpu/test-double-vlen2.c: Move most contents to,
and include ...
* sysdeps/x86_64/fpu/test-double-vlen2.h: ... here. New file.
* sysdeps/x86_64/fpu/test-double-vlen4-avx2.c: Move most contents
to, and include ...
* sysdeps/x86_64/fpu/test-double-vlen4-avx2.h: ... here. New
file.
* sysdeps/x86_64/fpu/test-double-vlen4.c: Move most contents to,
and include ...
* sysdeps/x86_64/fpu/test-double-vlen4.h: ... here. New file.
* sysdeps/x86_64/fpu/test-double-vlen8.c: Move most contents to,
and include ...
* sysdeps/x86_64/fpu/test-double-vlen8.h: ... here. New file.
* sysdeps/x86_64/fpu/test-float-vlen16.c: Move most contents to,
and include ...
* sysdeps/x86_64/fpu/test-float-vlen16.h: ... here. New file.
* sysdeps/x86_64/fpu/test-float-vlen4.c: Move most contents to,
and include ...
* sysdeps/x86_64/fpu/test-float-vlen4.h: ... here. New file.
* sysdeps/x86_64/fpu/test-float-vlen8-avx2.c: Move most contents
to, and include ...
* sysdeps/x86_64/fpu/test-float-vlen8-avx2.h: ... here. New file.
* sysdeps/x86_64/fpu/test-float-vlen8.c: Move most contents to,
and include ...
* sysdeps/x86_64/fpu/test-float-vlen8.h: ... here. New file.
Joseph Myers [Tue, 14 Feb 2017 00:15:48 +0000 (00:15 +0000)]
Move INIT_ARCH_EXT call from libm-test-support to libm-test-driver.
libmvec tests involve calling INIT_ARCH_EXT during initialization then
CHECK_ARCH_EXT before testing each function to see if the processor
being used for testing supports the required instruction set
extensions.
After my refactoring of libm-test infrastructure, the INIT_ARCH_EXT
call is in libm-test-support.c, built only once per floating-point
type. Now, in fact all definitions of this macro are empty, but given
that the definitions in sysdeps/x86_64/fpu/math-tests-arch.h are
conditional on REQUIRE_* macros defined in particular vector tests, it
seems more correct for the INIT_ARCH_EXT call to go instead in
libm-test-driver.c which gets built separately with those REQUIRE_*
macros properly defined. This patch moves the call there.
Tested for x86_64 and x86.
* math/libm-test-support.h: Do not include <math-tests-arch.h>
here.
* math/libm-test-support.c (libm_test_init): Do not call
INIT_ARCH_EXT here.
* math/libm-test-driver.c: Include <math-tests-arch.h>.
(main): Call INIT_ARCH_EXT.
ldbl-128: Fix y0 and y1 for -Inf input [BZ #21130]
The Bessel functions of the second type (Yn) are not defined for
negative input and should return NAN with the "invalid" exception
raised, in these cases. However, current code checks for infinity and
return zero, regardless of the sign. This error is exposed for long
double when linking with -lieee. Without this flag, the error is not
exposed, because the wrappers for these functions, which use
__kernel_standard functionality, return the correct value.
Tested for powerpc64le.
[BZ #21130]
* sysdeps/ieee754/ldbl-128/e_j0l.c (__ieee754_y0l): Return NAN
with the "invalid" exception raised when x is -Inf.
* sysdeps/ieee754/ldbl-128/e_j1l.c (__ieee754_y1l): Likewise.
Wilco Dijkstra [Fri, 10 Feb 2017 17:26:16 +0000 (17:26 +0000)]
GLIBC uses strchr (s, '\0') as an idiom to find the end of a string.
This is transformed into rawmemchr by the bits/string2.h header.
However this is generally slower than strlen on most targets, even when
an optimized rawmemchr implementation exists. Since GCC7 optimizes
strchr (s, '\0') to strlen (s) + s, the GLIBC headers should not
transform this to rawmemchr. As GCC recognizes strchr as a builtin,
defining strchr as the builtin is not useful.
H.J. Lu [Thu, 9 Feb 2017 20:19:44 +0000 (12:19 -0800)]
x86-64: Verify that _dl_runtime_resolve preserves vector registers
On x86-64, _dl_runtime_resolve must preserve the first 8 vector
registers. Add 3 _dl_runtime_resolve tests to verify that SSE,
AVX and AVX512 registers are preserved.
Joseph Myers [Thu, 9 Feb 2017 18:30:41 +0000 (18:30 +0000)]
Move more csin, csinh tests to auto-libm-test-in.
When I moved tests of csin and csinh to auto-libm-test-in, I didn't
move a few tests for which gen-auto-libm-tests was very slow because
of MPC slowness on certain inputs.
Now that auto-libm-test-out has been split up, such slowness only
affects regenerating the test expectations for the individual
functions in question, rather than any addition of tests for any
function to auto-libm-test-in. Thus, I no longer consider it a
problem to have these inputs in auto-libm-test-in, and this patch
moves them there. This results in test generation for csin and csinh
taking 5m43s (for each of csin and csinh) on my system, while other
functions are unaffected.
I expect the test generation to be much faster in MPC 1.1 (the
relevant performance improvements went in MPC mainline in Dec 2013,
but there hasn't been a release from mainline since then).
Tested for x86_64 and x86.
* math/auto-libm-test-in: Add more tests of csin and csinh.
* math/auto-libm-test-out-csin: Regenerated.
* math/auto-libm-test-out-csinh: Likewise.
* math/libm-test-csin.inc (csin_test_data): Remove tests moved to
auto-libm-test-in.
* math/libm-test-csinh.inc (csinh_test_data): Likewise.
Merge libm-compat-calls-auto and libm-compat-calls
Both libm-compat-calls and libm-compat-calls-auto list the functions
that must be built for the types float, double, and long double, but
not for other floating-point types that get added to libm. Besides
that, the use of libm-compat-calls-ldouble-yes to select if
w_lgamma_compatl and k_standardl should be built for long-double (in
libm-compat-calls) has the same effect of the use of type-foreach
(in libm-compat-calls-auto).
This patch merges the contents of libm-compat-calls into
libm-compat-calls-auto, then renames the latter to libm-compat-calls.
Tested for powerpc64le, s390, and x86_64.
* math/Makefile (libm-compat-calls-ldouble-yes): Merge into
libm-compat-calls-auto.
(libm-compat-calls): Likewise.
(libm-compat-calls-auto): Rename to libm-compat-calls and add
w_lgamma_compatF and k_standardF (merged from the items above).
(libm-routines): Use libm-compat-calls, instead of
libm-compat-calls-auto, with type-foreach.
Joseph Myers [Thu, 9 Feb 2017 17:32:48 +0000 (17:32 +0000)]
Move -U__LIBC_INTERNAL_MATH_INLINES to test-math-inline.h.
The libm tests of inline functions undefine __NO_MATH_INLINES (from
math-CPPFLAGS) in test-math-inline.h, but __LIBC_INTERNAL_MATH_INLINES
via -U options in the makefile.
This is an odd inconsistency between the handling of the two macros.
It also depends on the ordering (in compilation commands) of the
various variables providing compiler options (which I think is why
it's using CPPFLAGS-*.c instead of CFLAGS-*.c).
This patch moves the undefine to test-math-inline.h, so improving
consistency and eliminating the dependency on the order in which
variables go in the compilation commands. The CPPFLAGS-*.c variables
are renamed to CFLAGS-*.c, matching those for the non-inline libm
function tests.
By moving the -U option to the header file, this should ensure that
ordering issues don't arise with a subsequent move of the options to
these tests to target-specific CFLAGS += ... variable settings (for
when tests for each function are build separately and so compilation
options need setting for many more makefile targets, for which
target-specific variable settings seem to be the most convenient form
to generate with iterators).
Joseph Myers [Wed, 8 Feb 2017 21:11:49 +0000 (21:11 +0000)]
Build most libm-test support code once per type.
libm-test-driver.c contains various functions used in the course of
libm testing, which are built as part of each test using this
machinery.
Currently, these functions get built for three tests for each type
(e.g. test-float, test-ifloat, test-float-finite), plus the vector
function tests. All these tests are huge and thus slow to build; the
output of gen-libm-test.pl totals around 40 MB across all functions.
To make the individual tests built from the Makefile smaller, it makes
sense to split these tests up so the tests for each function are built
separately (thus, three tests for each (function, type) pair, plus
vector tests built only for functions that actually have vector
versions). This improves parallelism and means that if tests fail,
the summary of failed tests makes it more obvious where the problem
might be without needing to look in the .out files to see which
functions' tests failed (though architecture maintainers still need to
keep libm-test-ulps up to date to avoid spurious failures of little
interest).
Simply including libm-test-driver.c as-is in such individual-function
tests does not work because of unused static check_* functions (those
functions only being used for the types of the outputs of the function
under test). It also means the common code gets built over 1000 times
instead of nine (plus vector tests). To avoid that issue, this patch
splits out the bulk of the libm-test-driver.c code into a separate
file libm-test-support.c (with a few functions made non-static). That
separate file is built only once for each floating-point type (so at
present three times, or twice on architectures with long double =
double). Definitions needed in both libm-test-support.c and
libm-test-driver.c go in libm-test-support.h (it's possible some of
those are in fact only needed in one of the two files).
libm-test-driver.c keeps definitions of a limited number of variables
used to configure how libm-test-support.c behaves, various macros and
structures needed by individual-function tests, and the main function.
This move is also consistent in spirit with the move away from
test-skeleton.c having all the test support code, to a small
support/test-driver.c included in individual tests with most of the
code built separately.
* sysdeps/ieee754/ldbl-64-128/w_expl.c: Add suffix "_compat"
to filename.
* sysdeps/ieee754/ldbl-opt/w_exp.c: Likewise.
* sysdeps/ieee754/ldbl-64-128/w_expl_compat.c: New file,
copied from above and adjusted for the new filenames.
* sysdeps/ieee754/ldbl-opt/w_exp_compat.c: Likewise.
This patch adds the suffix "_compat2" to the wrappers for lgamma,
which use _LIB_VERSION / matherr / __kernel_standard functionality.
The suffix "_compat2" is used because the suffix "_compat" is already
used.
This patch adds the suffix "_compat" to lgamma_r wrappers and make
some adjustments to #includes and Makefiles. This is a step towards
deprecation of wrappers that use _LIB_VERSION / matherr /
__kernel_standard functionality.
* sysdeps/ieee754/ldbl-opt/w_lgamma_r.c: Add suffix "_compat"
to filename.
* sysdeps/ieee754/ldbl-opt/w_lgammal_r.c: Likewise.
* sysdeps/ieee754/ldbl-opt/w_lgamma_r_compat.c: New file
copied from above and adjusted for the new filenames.
* sysdeps/ieee754/ldbl-opt/w_lgammal_r_compat.c: Likewise.
aarch64: fix errno address calculation in SYSCALL_ERROR_HANDLER
This patch fixes the last regression in LTP lite scenario (mmap16) comparing
to lp64 in my source trees [1, 2]. The fix has been suggested back in 2015 [3]
but was never applied.
Checked on aarch64-linux-gnu.
* sysdeps/unix/sysv/linux/aarch64/sysdep.h: use PTR_REG() for offset
calculation in SYSCALL_ERROR_HANDLER().
Fix getting tunable values on big-endian (BZ #21109)
The code to set value passed a tunable_val_t, which when cast to
int32_t on big-endian gives the wrong value. Instead, use
tunable_val_t.numval instead, which can then be safely cast into
int32_t.
Kir Kolyshkin [Tue, 7 Feb 2017 08:06:05 +0000 (00:06 -0800)]
Add Linux PTRACE_EVENT_STOP
Add PTRACE_EVENT_STOP value to Linux's sys/ptrace.h, modify related
comments accordingly.
This constant initially appeared in Linux 3.1 (kernel commit 3544d72a,
"ptrace: implement PTRACE_SEIZE") but its value has changed later
in Linux 3.4 (kernel commit 5cdf389a, "ptrace: renumber
PTRACE_EVENT_STOP so that future new options and events can match").
The comment is also taken from the above commit.
This constant is used by e.g. strace, CRIU, Mozilla RR.
Joseph Myers [Tue, 7 Feb 2017 23:06:19 +0000 (23:06 +0000)]
Clean up libm vector tests exception test disabling.
The libm vector tests disable tests of exception raising via defining
macros EXCEPTION_TESTS_float and EXCEPTION_TESTS_double to 0 in the
headers for individual vector lengths.
As EXCEPTION_TESTS is used in code in libm-test-driver.c that is
otherwise ready to be built only once per type, this is not a good
idea; it's better to define TEST_EXCEPTIONS appropriately so that
flag_test_exceptions then gets initialized appropriately.
Furthermore, it's better to do this just once, in test-math-vector.h,
since there is no actual dependence on the vector length or type.
This patch duly makes that change.
Joseph Myers [Tue, 7 Feb 2017 17:15:47 +0000 (17:15 +0000)]
Fix powf inaccuracy (bug 21112).
Bug 21112 reports a case where powf is substantially inaccurate. This
results from a multiplication where cp_h*p_h is required to be exact,
and p_h is masked to have only 12 leading nonzero bits in its
mantissa, but the value of cp_h has the 13th bit nonzero, leading to
inexact multiplication results in some cases that can result in large
errors in the final result of powf. This patch fixes this by using a
value of cp_h correctly rounded to nearest to 12 bits, with a
corresponding updated value of cp_l.
Tested for x86_64 and x86.
[BZ #21112]
* sysdeps/ieee754/flt-32/e_powf.c (cp_h): Use value with trailing
12 bits zero.
(cp_l): Update for new value of cp_h.
* math/auto-libm-test-in: Add another test of pow.
* math/auto-libm-test-out-pow: Regenerated.
powerpc: Improve strcmp performance for shorter strings
For strings >16B and <32B existing algorithm takes more time than default
implementation when strings are placed closed to end of page. This is due
to byte by byte access for handling page cross. This is improved by
following >32B code path where the address is adjusted to aligned memory
before doing load doubleword operation instead of loading bytes.
Joseph Myers [Mon, 6 Feb 2017 23:23:54 +0000 (23:23 +0000)]
Refactor some code in libm-test-driver.c.
Splitting libm tests by function will mean about a thousand such tests
built separately instead of the present nine (plus vector variants).
When this is done, it's desirable to avoid needing to build all the
test infrastructure so many times. Also, simply including
libm-test-driver.c as-is into per-function tests doesn't actually
work, because the various check_* functions are not used by all tests
and so generate errors for unused static functions.
Although some pieces of infrastructure depend on the type being tested
while others don't, building once per type seems the simplest
approach. This patch makes changes to libm-test-driver.c in
preparation for that. Various cases where functions directly use
macros such as TEST_ERRNO (that may vary depending on things other
than the type under test) are changed to use variables initialized
using those macros, while most of the code in main is moved out to
functions libm_test_init and libm_test_fini.
The idea is that all the functions in libm-test-driver.c will be moved
out in a subsequent patch to be built once per type (and be no longer
static when they are used from per-function tests), while
libm-test-driver.c remains containing definitions of various variables
(no longer static, of course, because they'll be used in the per-type
code) and the main function. Declarations / macros relevant to both
the once-per-type code and the per-function tests will go in a shared
header.
Tested for x86_64.
* math/libm-test-driver.c (flag_test_errno): New variable.
(flag_test_exceptions): Likewise.
(flag_test_finite): Likewise.
(flag_test_inline): Likewise.
(flag_test_mathvec): Likewise.
(test_msg): Likewise.
(ulp_idx): Likewise.
(qtype_str): Likewise.
(ULP_IDX): Remove macro.
(QTYPE_STR): Likewise.
(find_ulps): Use ulp_idx not ULP_IDX.
(print_function_ulps): Use qtype_str, printed with %s, not
QTYPE_STR, printed with concatentation to format string.
(print_complex_function_ulps): Likewise.
(test_exceptions): Use flag_test_exceptions not TEST_EXCEPTIONS.
(test_errno): Use flag_test_errno not TEST_ERRNO.
(enable_test): Use flag_test_inline, flag_test_finite and
flag_test_mathvec instead of TEST_INLINE, TEST_FINITE and
TEST_MATHVEC.
(libm_test_init): New function. Factored out of main.
(libm_test_finish): Likewise.
(main): Call libm_test_init and libm_test_finish and move most
code to those functions.
Joseph Myers [Mon, 6 Feb 2017 23:07:22 +0000 (23:07 +0000)]
Move libm-test TEST_MSG definitions to libm-test-driver.c.
Various files using the libm-test infrastructure define a TEST_MSG
macro with an informal description of the tests being run.
This patch moves this macro to libm-test-driver.c (the definition
depending on other macros already defined), so files specific to
(type, choice of whether to test inline functions or finite-math-only
functions, vector length) no longer need to define it. This is in
preparation for replacing files such as test-float.c with per-function
test-float-<func>.c etc. automatically generated in the build
directory when tests are run.
Joseph Myers [Mon, 6 Feb 2017 18:57:25 +0000 (18:57 +0000)]
Split libm-test.inc by function.
Continuing the process of splitting up libm tests into more reasonably
sized units, this patch splits libm-test.inc into 121 separate
libm-test-<function>.inc files, one per array of test data. (There
are 126 libm *_test functions, but five of those are for functions
that are aliases for test purposes and so share arrays of test data.)
In the present patch, the 121 files get processed separately by
gen-libm-test.pl, each using only the auto-libm-test-out-<function>
file that is relevant (/dev/null for functions not using
auto-libm-test-* at all). This effectively eliminates the
serialization on running gen-libm-test.pl. However, the resulting .c
files still all get #included together, so compiling the limited
number of libm tests using libm-test.inc may still act as a
serialization point (the compilations still all have 40 MB of code to
process). libm-test.inc doesn't actually have anything in it any more
that needs gen-libm-test.pl processing, but is left as a .inc file
that gets processed to produce a .c file, rather than being renamed,
since the intent of this patch is as an intermediate step before
libm-test.inc gets removed and tests get compiled separately for each
function being tested.
Joseph Myers [Mon, 6 Feb 2017 18:41:20 +0000 (18:41 +0000)]
Split auto-libm-test-out by function.
math/auto-libm-test-out is, at over 30 MB, by far the largest file in
the glibc source tree. This patch splits it by function, so reducing
it to auto-libm-test-out-<func> files that are all under 5 MB in size.
This is preliminary to splitting up libm-test.inc as well so that each
function's tests can also be processed separately by
gen-libm-test.pl. As a preliminary patch it doesn't actually
implement that step; rather, all the separate files get concatenated
by the Makefile to produce the monolithic auto-libm-test-out file
again as an input to gen-libm-test.pl. (The concatentation is
identical to the file in the source tree before this patch.)
Even this preliminary step, however, is of use independent of
splitting up libm-test.inc: some tests for csin and csinh have not
been moved to auto-libm-test-in because they result in
auto-libm-test-out generation taking several minutes rather than a few
seconds (all released MPC versions are very slow for certain sin /
sinh inputs; there are some old improvements in MPC mainline which
should eventually become MPC 1.1, but the complex inverse trig and
hyperbolic functions are slow even in MPC mainline and have yet to be
moved to auto-libm-test-in at all), and it seems much more reasonable
to add such inputs to auto-libm-test-in when it will only slow down
regeneration for particular functions than when it will slow down
regeneration globally.
gen-auto-libm-tests still parses the whole input file, but only
generates output for the requested function. This ensures bad syntax
in the file is always detected, and parsing the whole file is quick;
it's output generation that is comparatively slow for some functions.
Joseph Myers [Mon, 6 Feb 2017 18:28:33 +0000 (18:28 +0000)]
Eliminate libm-test.stmp.
math/Makefile uses libm-test.stmp to handle dependencies involving
multiple generated files all generated by a single sequence of
commands in a single Makefile rule.
Having separated the libm-test-ulps.h and libm-test.c generation into
separate runs of gen-libm-test.pl, there is now no need for a single
rule to generate multiple target files; each of the three target files
involved can be generated by a separate Makefile rule, meaning normal
dependencies on the individual files can be used and so libm-test.stmp
is not needed at all. This patch does just that, eliminating the
.stmp file, in further preparation for when there are many separate
libm-test-<func>.c files generated from libm-test-<func>.inc and the
dependencies are on just the relevant .c file in each case.
Tested for x86_64.
* math/Makefile (generated): Do not include libm-test.stmp.
($(addprefix $(objpfx), $(libm-tests-generated))): Do not depend
on $(objpfx)libm-test.stmp.
($(objpfx)libm-test.stmp): Remove rule.
($(objpfx)libm-test-ulps.h): New rule.
($(objpfx)libm-test.c): Likewise.
($(objpfx)libm-have-vector-test.h): Likewise.
($(addprefix $(objpfx), $(libm-tests.o)): Depend directly on
individual generated files, not libm-test.stmp.
Joseph Myers [Mon, 6 Feb 2017 18:20:15 +0000 (18:20 +0000)]
Rework gen-libm-test.pl input/output handling.
This patch reworks how input and output files are specified for
gen-libm-test.pl.
Previously, the script had names of various inputs and outputs
hardcoded, with a -o option to specify an output directory. This
patch replaces this with all inputs and outputs being specified
explicitly as the arguments of options passed to the script. Outputs
are only generated if the relevant option is passed, and only the
processing required for the indicated outputs is done. The Makefile
is made to pass options for generating libm-test-ulps.h in a separate
invocation of gen-libm-test.pl from that generating libm-test.c.
This is all in preparation for splitting up libm-test.inc and
auto-libm-test-out and running tests separately for each function,
when gen-libm-test.pl will be run separately for each function to
generate the .c file but only once to generate libm-test-ulps.h (and
those runs will be able to be in parallel).
Tested for x86_64. The generated libm-test.c and libm-test-ulps.h are
identical before and after the patch. Also tested the "make
regen-ulps" case.
* math/gen-libm-test.pl ($output_dir): Remove variable.
($srcdir): Likewise.
($opt_a): New variable.
($opt_c): Likewise.
($opt_C): Likewise.
($opt_H): Likewise.
(-n): Make option take argument and use it as NewUlps output.
(-a): New option. Use its argument for auto-libm-test-out input.
(-c): New option. Use its argument for libm-test.inc input.
(-C): New option. Use its argument for libm-test.c output.
(-H): New option. Use its argument for libm-test-ulps.h output.
(top level): Only process inputs needed to generate outputs
specified by command-line options. Only generate outputs
specified by command-line options.
* math/README.libm-test: Update example gen-libm-test.pl command.
* math/Makefile ($(objpfx)libm-test.stmp): Update gen-libm-test.pl
commands.
(regen-ulps): Likewise.
Wilco Dijkstra [Mon, 6 Feb 2017 18:14:16 +0000 (18:14 +0000)]
As a minor cleanup remove the (r)index defines from include/string.h as
they are only used internally in a few places. Rename all uses that
occur in GLIBC.
* hurd/path-lookup.c (file_name_path_scan): Rename index to strchr.
* include/string.h (index): Remove define.
(rindex): Likewise.
* misc/getttyent.c (__getttyent): Rename index to strchr.
* misc/ttyslot.c (ttyslot): Rename rindex to strrchr.
* sunrpc/rpc_main.c (mkfile_output): Likewise.
Joseph Myers [Mon, 6 Feb 2017 18:12:16 +0000 (18:12 +0000)]
Move non-function-specific parts of libm-test.inc to separate file.
libm-test.inc contains both test infrastructure and tests of
individual functions.
This patch moves the infrastructure to a separate file
libm-test-driver.c. This is in preparation for splitting the tests of
individual functions into separate source files, which will be
processed individually by gen-libm-test.pl (so e.g. libm-test-acos.inc
and auto-libm-test-out-acos will be processed by gen-libm-test.pl to
produce libm-test-acos.c, and files such as test-double-acos.c will be
generated by the Makefile to include appropriate headers,
libm-test-driver.c and libm-test-acos.c so tests of each function get
run separately).
It is no doubt possible to split things up further, so that functions
not depending on the type being tested only get compiled once and most
of those depending on the type being tested get compiled once per type
(rather than separately for variants such as inline / no-inline, and
separately for each function being tested after that split), but this
rearrangement as-is seems a useful incremental step towards splitting
these tests by function.
Joseph Myers [Mon, 6 Feb 2017 18:02:54 +0000 (18:02 +0000)]
Remove libm-test.inc comment listing functions tested and not tested.
math/libm-test.inc has a comment listing the functions tested and not
tested. The list of functions tested duplicates what is immediately
obvious from the rest of the file and adds another place to update
when adding a function. I've put the information about functions not
tested on the wiki todo list; this patch removes that comment, in
preparation for splitting tests of each function into separate .inc
files with common code staying in a separate .c file.
Tested for x86_64.
* math/libm-test.inc: Remove comment listing functions tested and
not tested.
This patch removes the COLORING_INCREMENT define and usage on allocatestack.c.
It has not been used since 564cd8b67ec487f (glibc-2.3.3) by any architecture.
The idea is to simplify the code by removing obsolete code.
Joseph Myers [Mon, 6 Feb 2017 17:55:59 +0000 (17:55 +0000)]
Do not hardcode list of libm functions in libm-err-tab.pl.
manual/libm-err-tab.pl contains a hardcoded list of libm functions for
which ulps are listed in the manual, and another hardcoded list in a
comment of functions deliberately excluded because of an expected lack
of ulps (and the two together are not in fact an exhaustive list of
libm functions tested through the libm-test machinery).
This patch removes these hardcoded lists, so eliminating this from the
places needing updating when a new libm function is added. Instead,
ulps are tabulated for functions for which they are seen in
libm-test-ulps files, in alphabetical order. The pseudo-function
names such as *_downward and *_vlen* are excluded since they are
excluded from the existing lists, and the description in the manual is
updated to explain how those entries are excluded and if a function is
not listed at all it does not have known errors.
Tested for x86_64.
* manual/libm-err-tab.pl (@all_functions): Change to
%all_functions. Initialize as empty.
(parse_ulps): Add to %all_functions based on functions found in
ulps files. Ignore results for non-default rounding modes and
vector functions.
(print_platforms): Use %all_platforms.
* manual/math.texi (Errors in Math Functions): Document omissions
from the table.
Joseph Myers [Mon, 6 Feb 2017 17:48:02 +0000 (17:48 +0000)]
Remove before-compile setting in math/Makefile.
In <https://sourceware.org/ml/libc-alpha/2015-12/msg00543.html>,
Florian noted highly parallel builds being slowed down by
gen-libm-test.pl running during the build, when it should only run for
testing, not for building glibc itself.
This is a consequence of libm-test.c being listed in before-compile.
That listing in before-compile arose from the error reported in
<https://sourceware.org/ml/libc-hacker/1999-10/msg00054.html> when
building dependencies: at that time, dependencies were generated
separation from compilation, so if a source file included a generated
file it wasn't enough for the dependencies for the .o file to be
correct, the generated file needed to be listed in before-compile.
Since <https://sourceware.org/ml/libc-hacker/2003-05/msg00001.html>,
dependencies are generated as a side-effect of compilation. This
means that having the right dependencies for the .o files for the
tests fully suffices to ensure that libm-test.c is generated by the
time it's needed; no entry in before-compile is needed. And we indeed
have such a dependency for all the tests using libm-test.c:
Thus, the before-compile definition is unnecessary, and this patch
removes it. (This may of course move serialization from the glibc
build to glibc testing, but I intend to split up libm-test.inc so that
tests for each (floating-point type, libm function) pair are built and
run separately, which should reduce that serialization.)
Stefan Liebler [Mon, 6 Feb 2017 12:44:23 +0000 (13:44 +0100)]
Add __glibc_unlikely hint in lll_trylock, lll_cond_trylock.
The macros lll_trylock, lll_cond_trylock are extended by an __glibc_unlikely
hint. Now the trylock macros are based on the same assumption about a
free/busy lock as lll_lock.
With the hint gcc emits code in e.g. pthread_mutex_trylock which does
not use jumps if the lock is free. Without the hint it had to jump away
if the lock is free.
Remove i686, x86_64, and powerpc strtok implementations
Based on comments on previous attempt to address BZ#16640 [1],
the idea is not support invalid use of strtok (the original
bug report proposal). This leader to a new strtok optimized
strtok implementation [2].
The idea of this patch is to fix BZ#16640 to align all the
implementations to a same contract. However, with newer strtok
code it is better to get remove the old assembly ones instead of
fix them.
For x86 is a gain in all cases since the new implementation can
potentially use sse2/sse42 implementation for strspn and strcspn.
This shows a better performance on both i686 and x86_64 using
the string benchtests.
On powerpc64 the gains are mixed, where only for larger inputs
or keys some gains are showns (based on benchtest it seems that
it shows some gains for keys larger than 10 and inputs larger
than 32). I would prefer to remove the optimized implementation
based on first code simplicity and second because some more gain
could be optimized using a better optimized strcspn/strspn
code (as for x86). However if powerpc arch maintainers prefer I
can send a v2 with the assembly code adjusted instead.
Checked on x86_64-linux-gnu, i686-linux-gnu, and powerpc64le-linux-gnu.
Consolidate arm and mips posix_fadvise implementations
As noted by c1f0601389db64d9, previous posix_fadvise consolidation
broke on mips o32. As stated in commit message, MIPS o32 only defines
__NR_fadvise64 and it is behaves like __NR_fadvise64_64.
This patches consolidates both ARM and mips o32 version by fixing
the ARM used option (__NR_fadvise64_64 withouth the alignment required
by abi) and added another option, __ASSUME_FADVISE64_AS_64_64,
which is used on mips o32.
When this option is used, posix_fadvise will use __NR_fadvise64_64
behavior (by defining or not __ASSUME_FADVISE64_64_6ARG). For
mips, if __NR_fadvise64_64 is not defined, __NR_fadvise will be used.
I also updated the posix_fadvise comments to explain better the
different kernel abi used in the supported architectures.
I checked with a mips o32 and verified that posix_fadvise.o is
indeed using 7 argument syscall with the expected argument position.
I also checked on i686-linux-gnu and arm-gnu-eabihf.
* sysdeps/unix/sysv/linux/arm/posix_fadvise.c: Remove file.
* sysdeps/unix/sysv/linux/mips/mips32/posix_fadvise.c: Likewise.
* sysdeps/unix/sysv/linux/mips/kernel-features.h
(__ASSUME_FADVISE64_AS_64_64): Define.
* sysdeps/unix/sysv/linux/posix_fadvise.c [__NR_fadvise64]: Add
!defined __ASSUME_FADVISE64_AS_64_64 to use syscall issue.
[!__NR_fadvise64 && __ASSUME_FADVISE64_64_6ARG]: Remove
__ALIGNMENT_ARG usage.
[!__NR_fadvise64 && !__ASSUME_FADVISE64_64_6ARG]: Define
__NR_fadvise64_64 if it is not defined.
tunables: Fail tests correctly when setgid does not work
The child process of the tst-env-setuid process was failing correctly
with EXIT_UNSUPPORTED but the parent did not carry that status forward
and failed instead. This patch fixes this so that tests on nosuid
/tmp fails gracefully with UNSUPPORTED. Tested by making my tmpfs
nosuid.
* elf/tst-env-setuid.c (do_execve): Return EXIT_UNSUPPORTED in
parent if child exited in that manner. Print WEXITSTATUS
instead of the raw status.
(do_test_prep): Rename to do_test.
(do_test): Return the result of run_executable_sgid.
(TEST_FUNCTION_ARGV): Adjust.
Alexandre Oliva [Sat, 4 Feb 2017 01:35:16 +0000 (20:35 -0500)]
Bug 20915: Do not initialize DTV of other threads.
In _dl_nothread_init_static_tls() and init_one_static_tls() we must not
touch the DTV of other threads since we do not have ownership of them.
The DTV need not be initialized at this point anyway since only LD/GD
accesses will use them. If LD/GD accesses occur they will take care to
initialize their own thread's DTV.
Concurrency comments were removed from the patch since they need to be
reworked along with a full description of DTV ownership and when it is
or is not safe to modify these structures.
Alexandre Oliva's original patch and discussion:
https://sourceware.org/ml/libc-alpha/2016-09/msg00512.html
David S. Miller [Sat, 4 Feb 2017 01:48:39 +0000 (17:48 -0800)]
sparc: Remove optimized math routines which cause testsuite failures.
famx{,f}/fmin{,f} and 32-bit lrint cause math testsuite failures
either because they generate incorrect results or they fail to signal
the proper exceptions.
H.J. Lu [Thu, 2 Feb 2017 21:14:43 +0000 (13:14 -0800)]
Allow IFUNC relocation against unrelocated shared library
IFUNC relocation against definition in unrelocated shared library
will lead to segfault when the IFUNC function is called. This
patch allows such IFUNC relocations with a warning. This isn't
a real fix for
Drop GLIBC_TUNABLES for setxid programs when tunables is disabled (bz #21073)
A setxid program that uses a glibc with tunables disabled may pass on
GLIBC_TUNABLES as is to its child processes. If the child process
ends up using a different glibc that has tunables enabled, it will end
up getting access to unsafe tunables. To fix this, remove
GLIBC_TUNABLES from the environment for setxid process.
* sysdeps/generic/unsecvars.h: Add GLIBC_TUNABLES.
* elf/tst-env-setuid-tunables.c
(test_child_tunables)[!HAVE_TUNABLES]: Verify that
GLIBC_TUNABLES is removed in a setgid process.
tunables: Fix environment variable processing for setuid binaries (bz #21073)
Florian Weimer pointed out that we have three different kinds of
environment variables (and hence tunables):
1. Variables that are removed for setxid processes
2. Variables that are ignored in setxid processes but is passed on to
child processes
3. Variables that are passed on to child processes all the time
Tunables currently only does (2) and (3) when it should be doing (1)
for MALLOC_CHECK_. This patch enhances the is_secure flag in tunables
to an enum value that can specify which of the above three categories
the tunable (and its envvar alias) belongs to.
The default is for tunables to be in (1). Hence, all of the malloc
tunables barring MALLOC_CHECK_ are explicitly specified to belong to
category (2). There were discussions around abolishing category (2)
completely but we can do that as a separate exercise in 2.26.
Tested on x86_64 to verify that there are no regressions.
[BZ #21073]
* elf/dl-tunable-types.h (tunable_seclevel_t): New enum.
* elf/dl-tunables.c (tunables_strdup): Remove.
(get_next_env): Also return the previous envp.
(parse_tunables): Erase tunables of category
TUNABLES_SECLEVEL_SXID_ERASE.
(maybe_enable_malloc_check): Make MALLOC_CHECK_
TUNABLE_SECLEVEL_NONE if /etc/setuid-debug is accessible.
(__tunables_init)[TUNABLES_FRONTEND ==
TUNABLES_FRONTEND_valstring]: Update GLIBC_TUNABLES envvar
after parsing.
[TUNABLES_FRONTEND != TUNABLES_FRONTEND_valstring]: Erase
tunable envvars of category TUNABLES_SECLEVEL_SXID_ERASE.
* elf/dl-tunables.h (struct _tunable): Change member is_secure
to security_level.
* elf/dl-tunables.list: Add security_level annotations for all
tunables.
* scripts/gen-tunables.awk: Recognize and generate enum values
for security_level.
* elf/tst-env-setuid.c: New test case.
* elf/tst-env-setuid-tunables: new test case.
* elf/Makefile (tests-static): Add them.
H.J. Lu [Mon, 30 Jan 2017 18:59:15 +0000 (10:59 -0800)]
Add VZEROUPPER to memset-vec-unaligned-erms.S [BZ #21081]
Since memset-vec-unaligned-erms.S has VDUP_TO_VEC0_AND_SET_RETURN at
function entry, memset optimized for AVX2 and AVX512 will always use
ymm/zmm register. VZEROUPPER should be placed before ret in
Carlos O'Donell [Sun, 29 Jan 2017 00:13:34 +0000 (19:13 -0500)]
Bug 20116: Fix use after free in pthread_create()
The commit documents the ownership rules around 'struct pthread' and
when a thread can read or write to the descriptor. With those ownership
rules in place it becomes obvious that pd->stopped_start should not be
touched in several of the paths during thread startup, particularly so
for detached threads. In the case of detached threads, between the time
the thread is created by the OS kernel and the creating thread checks
pd->stopped_start, the detached thread might have already exited and the
memory for pd unmapped. As a regression test we add a simple test which
exercises this exact case by quickly creating detached threads with
large enough stacks to ensure the thread stack cache is bypassed and the
stacks are unmapped. Before the fix the testcase segfaults, after the
fix it works correctly and completes without issue.
For a detailed discussion see:
https://www.sourceware.org/ml/libc-alpha/2017-01/msg00505.html
James Clarke [Tue, 24 Jan 2017 11:20:06 +0000 (09:20 -0200)]
Bug 21053: sh: Reduce namespace pollution from sys/ucontext.h
The problem is basically that sys/ucontext.h is defining R0..R15
which happens to conflict with some packages like Firefox when
trying to build on SH.
The very same problem existed on arm back then [1] and it was fixed by
renaming R0..R15 to REG_R0..REG_R15. This patch imploy a similar
strategy for SH.
Checked on sh4-linux-gnu with run-built-tests=no and I also got reports
that it fixes Firefox build on Debian sh4.
* sysdeps/unix/sysv/linux/sh/sh3/ucontext_i.sym: Use new REG_R*
constants instead of the old R* ones.
* sysdeps/unix/sysv/linux/sh/sh4/ucontext_i.sym: Likewise.
* sysdeps/unix/sysv/linux/sh/sys/ucontext.h (NGPREG): Rename...
(NGREG): ... to this, to fit in with other architectures.
(gpregset_t): Use new NGREG macro.
[__USE_GNU]: Remove condition; all architectures other than tile
are unconditional.
(R*): Rename to REG_R*.
DJ Delorie [Sat, 21 Jan 2017 00:52:52 +0000 (19:52 -0500)]
* elf/dl-tunables.c (tunable_set_val_if_valid_range): Split into ...
(tunable_set_val_if_valid_range_signed) ... this, and ...
(tunable_set_val_if_valid_range_unsigned) ... this.
(tunable_initialize): Call the correct one of the above based on type.
Joseph Myers [Fri, 20 Jan 2017 23:58:49 +0000 (23:58 +0000)]
Remove very old libm-test-ulps entries.
I noticed that some libm-test-ulps files still had long-obsolete
entries for *_tonearest functions, which will no longer be used since
functions with FE_TONEAREST explicitly set aren't tested separately
from those functions with it as the default rounding mode any more.
This patch removes those obsolete entries. However, as they are a
sign of libm-test-ulps not having been regenerated from scratch for a
long time, I strongly advise people testing on those platforms to
remove / truncate the libm-test-ulps file, run "make regen-ulps" and
commit the regenerated-from-scratch file. (Ideally any failures of
libm tests still present after regeneration would be investigated /
fixed - there are several open "math" bugs spread across these
platforms - but simply regenerating from scratch improves things.)
Joseph Myers [Fri, 20 Jan 2017 23:25:13 +0000 (23:25 +0000)]
Update README.libm-test.
This patch updates math/README.libm-test to have a more complete and
up-to-date list of the characters used in TEST_* macros to indicate
the types of function inputs and outputs.
* math/README.libm-test: Update list of characters for input and
output types.
Torvald Riegel [Fri, 20 Jan 2017 13:54:49 +0000 (14:54 +0100)]
Fix mutex pretty printer test and pretty printer output.
This fixes the mutex pretty printer so that, if the owner ID isn't recorded
(such as in the current lock elision implementation), "Owner ID" will be shown
as "Unknown" instead of 0. It also changes the mutex printer output so that it
says "Acquired" instead of "Locked". The mutex tests are updated accordingly.
In addition, this adds a paragraph to the "Known issues" section of the
printers README explaining that the printer output isn't guaranteed to cover
every detail.
2017-01-14 Martin Galvan <martingalvan@sourceware.org>
* README.pretty-printers (Known issues): Warn about printers not
always covering everything.
* nptl/nptl-printers.py (MutexPrinter): Change output.
* nptl/test-mutex-printers.py: Fix test and adapt to changed output.
The futex value is not tested before starting a transaction,
__glibc_likely is used instead of __builtin_expect and comments
are adjusted.
ChangeLog:
* sysdeps/unix/sysv/linux/s390/htm.h: Adjust comments.
* sysdeps/unix/sysv/linux/s390/elision-unlock.c: Likewise.
* sysdeps/unix/sysv/linux/s390/elision-lock.c: Adjust comments.
(__lll_lock_elision): Do not test futex before starting a
transaction. Use __glibc_likely instead of __builtin_expect.
* sysdeps/unix/sysv/linux/s390/elision-trylock.c: Adjust comments.
(__lll_trylock_elision): Do not test futex before starting a
transaction. Use __glibc_likely instead of __builtin_expect.
Joseph Myers [Thu, 19 Jan 2017 20:57:16 +0000 (20:57 +0000)]
Restore clock_* librt exports for MicroBlaze (bug 21061).
MicroBlaze had clock_* functions exported from librt in glibc 2.18 and
2.19, as confirmed in
<https://sourceware.org/ml/libc-alpha/2017-01/msg00369.html>, and they
then disappeared in 2.20, presumably as a result of the fix
<https://sourceware.org/ml/libc-alpha/2014-02/msg00598.html> for a
Versions.def bug that had resulted in their unintended inclusion in
2.18 (followed by removal of the Versions.def mechanism that allowed
such bugs).
As they were released in that library, they should be considered part
of the GLIBC_2.18 ABI and so restored for the sake of any binaries
that expect them in that library. This patch restores them by adding
a MicroBlaze version of clock-compat.c that overrides SHLIB_COMPAT.
Tested (compilation only) with build-many-glibcs.py (where this fixes
the librt ABI test failure; elf/check-execstack still fails and still
needs architecture maintainer attention to fix it or XFAIL it with an
appropriate explanatory comment).
[BZ #21061]
* sysdeps/unix/sysv/linux/microblaze/clock-compat.c: New file.
Fix environment traversal when an envvar value is empty
The condition when the value of an envvar is empty (not just '\0'),
the loop in tunables_init gets stuck infinitely because envp is not
incremented. Fix that by always incrementing envp in the loop.
Added test case (tst-empty-env.c) verifies the fix when the source is
configured with --enable-hardcoded-path-in-tests, thanks Josh Stone for
providing the test case. Verified on x86_64.
* elf/dl-tunables (get_next_env): Always advance envp.
* stdlib/tst-empty-env.c: New test case.
* stdlib/Makefile (tests): Use it.
Joseph Myers [Thu, 19 Jan 2017 00:05:34 +0000 (00:05 +0000)]
Fix ARM fpu_control.h for assemblers requiring VFP insn names (bug 21047).
Bug 21047 reports that the clang assembler disallows the ARM
implementations of _FPU_GETCW and _FPU_SETCW.
These are deliberately written the way they are, using generic
coprocessor instructions (from the days when VFP was just one possible
coprocessor for ARM) that have the right encodings, to handle the case
of the instructions being used runtime-conditionally inside glibc,
where use of these macros is not meant to result in either the
assembler requiring VFP to be enabled at assembly time or in it
marking the object as using VFP. However, more recent ARM ARM
versions have restricted the definitions of the coprocessor
instructions and reportedly the clang assembler follows that in
disallowing those names for VFP instructions.
In the non-__SOFTFP__ case - which in fact is the only case where
these macro definitions can be used outside the build of glibc itself
- using VFP instruction names is of course fine, since we know that
VFP is enabled for that compilation. Thus, this patch uses the
current VFP names for these instructions in that case to improve
compatibility for this header file.
Tested for hard-float and soft-float builds of glibc, including that
installed stripped shared libraries are unchanged by the patch.
[BZ #21047]
* sysdeps/arm/fpu_control.h [!__SOFTFP__] (_FPU_GETCW): Use VFP
name for instruction.
[!__SOFTFP__] (_FPU_SETCW): Likewise.
Joseph Myers [Wed, 18 Jan 2017 23:13:09 +0000 (23:13 +0000)]
Avoid parallel GCC install in build-many-glibcs.py.
A recent build-many-glibcs.py build
<https://sourceware.org/ml/libc-testresults/2017-q1/msg00067.html> ran
into what proves to be an old known bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980> with parallel
install of GCC (one which as discussed there might require automake
changes to fix). This patch makes build-many-glibcs.py avoid such
intermittent failures from parallel install by using -j1 for GCC make
install (the code in question also applies to binutils make install,
but it doesn't seem worth trying to avoid -j1 there; the builds and
installs of different toolchains are still fully parallel with each
other, this is only about the case when there are few enough of those
that multiple jobs can get used within a single make install).
* scripts/build-many-glibcs.py (Config.build_cross_tool): Use -j1
for make install.
Stefan Liebler [Tue, 17 Jan 2017 07:54:58 +0000 (08:54 +0100)]
S390: Fix FAIL in test string/tst-xbzero-opt [BZ #21006]
On s390x this test failed with:
FAIL: explicit clear/test: expected 0 got 1
In setup_explicit_clear, the buffer is filled with the test_pattern.
On s390x the memcpy in prepare_test_buffer is done by loading
r4 / r5 with the test_pattern and using store multiple instruction
to store r4 / r5 to buf.
If explicit_bzero is resolved in setup_explicit_clear, r4 / r5 is
stored to stack by _dl_runtime_resolve and the call to memmem in
count_test_patterns finds a hit of the test_pattern on the stack.
This patch resolves all symbols at program startup by linking with
-z now. This omits the call of _dl_runtime_resolve within
setup_explicit_clear and the test passes.
ChangeLog:
[BZ #21006]
* string/Makefile (LDFLAGS-tst-xbzero-opt): New variable.
Joseph Myers [Mon, 16 Jan 2017 21:34:48 +0000 (21:34 +0000)]
Make soft-float powerpc swapcontext restore the signal mask (bug 21045).
The soft-float powerpc version of swapcontext does not restore the
signal mask, resulting in stdlib/tst-setcontext2 failing:
after getcontext
after setcontext
after swapcontext
FAIL: SIGUSR2 is blocked after swapcontext.
This patch fixes this by adjusting the arguments passed to
__sigprocmask so that it restores the saved signal mask as well as
saving the existing one. (For hard-float, this code is only used for
a compat symbol, not for the current version of swapcontext.)
Tested for soft-float powerpc.
[BZ #21045]
* sysdeps/unix/sysv/linux/powerpc/powerpc32/swapcontext-common.S
(__CONTEXT_FUNC_NAME): Pass address of signal mask to be restored
to __sigprocmask.
Chris Metcalf [Mon, 16 Jan 2017 20:38:25 +0000 (15:38 -0500)]
tile: Check for pointer add overflow in memchr
As was done in b224637928e9, check for large size causing an overflow
in the loop that walks over the array.
Branching out of line here is the fastest approach for handling this
problem, since tile can bundle the instructions to compute the branch
test in parallel with doing the required memchr loop setup computation.
Unfortunately, the existing saturated ops (e.g. tilegx addxsc) are
all signed saturing ops, so don't help with unsigned saturation.
Chris Metcalf [Thu, 12 Jan 2017 15:19:43 +0000 (10:19 -0500)]
tile: pass __IPC_64 as zero for SysV IPC calls
In 1e5834c38a22 ("Refactor Linux ipc_priv header") a different
approach to passing __IPC_64 as zero was created. The tile
architecture also needs to pass __IPC_64 as zero since it does
not set CONFIG_ARCH_WANT_IPC_PARSE_VERSION in the kernel.
So create a minimal ipc_priv.h that specifies __IPC_64 as zero.
The ip6-bytestring resolver corresponds to the RES_USEBSTRING flag and
not RES_NOIP6DOTINT. Thank you Michael Kerrisk for noticing and
pointing it out.
Torvald Riegel [Fri, 23 Dec 2016 23:40:46 +0000 (00:40 +0100)]
Add compiler barriers around modifications of the robust mutex list.
Any changes to the per-thread list of robust mutexes currently acquired as
well as the pending-operations entry are not simply sequential code but
basically concurrent with any actions taken by the kernel when it tries
to clean up after a crash. This is not quite like multi-thread concurrency
but more like signal-handler concurrency.
This patch fixes latent bugs by adding compiler barriers where necessary so
that it is ensured that the kernel crash handling sees consistent data.
This is meant to be easy to backport, so we do not use C11-style signal
fences yet.
Torvald Riegel [Wed, 21 Dec 2016 12:37:19 +0000 (13:37 +0100)]
Clear list of acquired robust mutexes in the child process after forking.
Robust mutexes acquired at the time of a call to fork() do not remain
acquired by the forked child process. We have to clear the list of
acquired robust mutexes before registering this list with the kernel;
otherwise, if some of the robust mutexes are process-shared, the parent
process can alter the child's robust mutex list, which can lead to
deadlocks or even modification of memory that may not be occupied by a
mutex anymore.
[BZ #19402]
* sysdeps/nptl/fork.c (__libc_fork): Clear list of acquired robust
mutexes.
Torvald Riegel [Thu, 22 Dec 2016 09:20:43 +0000 (10:20 +0100)]
robust mutexes: Fix broken x86 assembly by removing it
lll_robust_unlock on i386 and x86_64 first sets the futex word to
FUTEX_WAITERS|0 before calling __lll_unlock_wake, which will set the
futex word to 0. If the thread is killed between these steps, then the
futex word will be FUTEX_WAITERS|0, and the kernel (at least current
upstream) will not set it to FUTEX_OWNER_DIED|FUTEX_WAITERS because 0 is
not equal to the TID of the crashed thread.
The lll_robust_lock assembly code on i386 and x86_64 is not prepared to
deal with this case because the fastpath tries to only CAS 0 to TID and
not FUTEX_WAITERS|0 to TID; the slowpath simply waits until it can CAS 0
to TID or the futex_word has the FUTEX_OWNER_DIED bit set.
This issue is fixed by removing the custom x86 assembly code and using
the generic C code instead. However, instead of adding more duplicate
code to the custom x86 lowlevellock.h, the code of the lll_robust* functions
is inlined into the single call sites that exist for each of these functions
in the pthread_mutex_* functions. The robust mutex paths in the latter
have been slightly reorganized to make them simpler.
This patch is meant to be easy to backport, so C11-style atomics are not
used.
Joseph Myers [Thu, 12 Jan 2017 02:19:00 +0000 (02:19 +0000)]
Fix MIPS o32 posix_fadvise.
The posix_fadvise consolidation broke posix_fadvise for MIPS o32, so
resulting in posix/tst-posix_fadvise failing.
MIPS o32 (and the other ABIs) has only the posix_fadvise64 syscall,
which acts like posix_fadvise64_64 (in the o32 case, because of the
alignment argument it's actually a 7-argument syscall). The generic
posix_fadvise implementation presumes that if __NR_fadvise64 is
defined, it's for the case where a single len argument is passed to
the syscall rather than two syscall arguments in the case of a 32-bit
system.
The generic posix_fadvise64 works fine for this case (defining
__NR_fadvise64_64 to __NR_fadvise64 as needed). ARM has a
posix_fadvise.c that uses __posix_fadvise64_l64 in posix_fadvise, and
that approach also works for MIPS o32, so this patch makes MIPS o32
include the ARM file.
Tested for MIPS o32.
* sysdeps/unix/sysv/linux/mips/mips32/posix_fadvise.c: New file.
Joseph Myers [Thu, 12 Jan 2017 01:52:37 +0000 (01:52 +0000)]
Make fallback fegetexceptflag work with generic fetestexceptflag.
The generic implementation of fetestexceptflag does:
int
fetestexceptflag (const fexcept_t *flagp, int excepts)
{
/* Most versions of fegetexceptflag store exceptions in a form such
that this works. */
return *flagp & excepts & FE_ALL_EXCEPT;
}
In the case where FE_ALL_EXCEPT is nonzero but exceptions may not be
supported at runtime, this only works if fegetexceptflag cleared all
the bits of FE_ALL_EXCEPT in *flagp; otherwise it accesses
uninitialized data. This showed up as a failure of
math/test-fetestexceptflag for MIPS o32 soft-float. This patch makes
the fallback fegetexceptflag store 0 (fexcept_t is an integer type
everywhere) so that this works. (No bug report in Bugzilla because
this wasn't user-visible - at least, without using tools to detect
uninitialized memory use at runtime - without fetestexceptflag, which
is new in 2.25.)
Tested for MIPS o32 soft-float.
* math/fgetexcptflg.c (__fegetexceptflag): Store 0 in fexcept_t
object.
Joseph Myers [Wed, 11 Jan 2017 15:28:08 +0000 (15:28 +0000)]
Make endian-conversion macros always return correct types (bug 16458).
Bug 16458 reports that the endian-conversion macros in <endian.h> and
<netinet/in.h>, in the case where no endian conversion is needed, just
return their arguments without converting to the expected return type,
so failing to act as expected for a macro version of a function. (The
<netinet/in.h> macros, in particular, are described with prototypes in
POSIX so should act like correspondingly prototyped functions.)
Where previously this was a fairly obscure issue, it now results in
glibc build with GCC mainline breaking for big-endian systems:
nss_hesiod/hesiod-service.c: In function '_nss_hesiod_getservbyport_r':
nss_hesiod/hesiod-service.c:142:39: error: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size 6 [-Werror=format-truncation=]
snprintf (portstr, sizeof portstr, "%d", ntohs (port));
^~
nss_hesiod/hesiod-service.c:142:38: note: using the range [1, -2147483648] for directive argument
snprintf (portstr, sizeof portstr, "%d", ntohs (port));
^~~~
nss_hesiod/hesiod-service.c:142:3: note: format output between 2 and 12 bytes into a destination of size 6
snprintf (portstr, sizeof portstr, "%d", ntohs (port));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The port argument is passed as int to this function, so when ntohs
does not convert the compiler cannot tell that the result is within
the range of uint16_t. (I don't know if in fact it's possible for
out-of-range values to reach this function and so get truncated as
strings without this patch or as integers with it.)
This patch arranges for these macros to use identity functions to
ensure appropriate conversions while having warnings for implicit
conversions of function arguments that might not occur with a cast.
Tested for x86_64 and x86; with build-many-glibcs.py with GCC 6; and
with build-many-glibcs.py with GCC mainline for powerpc to test the
build fix.
[BZ #16458]
* bits/uintn-identity.h: New file.
* inet/netinet/in.h: Include <bits/uintn-identity.h>.
[__BYTE_ORDER == __BIG_ENDIAN] (ntohl): Use __uint32_identity.
[__BYTE_ORDER == __BIG_ENDIAN] (ntohs): Use __uint16_identity.
[__BYTE_ORDER == __BIG_ENDIAN] (htonl): Use __uint32_identity.
[__BYTE_ORDER == __BIG_ENDIAN] (htohs): Use __uint16_identity.
* string/endian.h: Include <bits/uintn-identity.h>.
[__BYTE_ORDER == __LITTLE_ENDIAN] (htole16): Use
__uint16_identity.
[__BYTE_ORDER == __LITTLE_ENDIAN] (le16toh): Likewise.
[__BYTE_ORDER == __LITTLE_ENDIAN] (htole32): Use
__uint32_identity.
[__BYTE_ORDER == __LITTLE_ENDIAN] (le32toh): Likewise.
[__BYTE_ORDER == __LITTLE_ENDIAN] (htole64): Use
__uint64_identity.
[__BYTE_ORDER == __LITTLE_ENDIAN] (le64toh): Likewise.
[__BYTE_ORDER != __LITTLE_ENDIAN] (htobe16): Use
__uint16_identity.
[__BYTE_ORDER != __LITTLE_ENDIAN] (be16toh): Likewise.
[__BYTE_ORDER != __LITTLE_ENDIAN] (htobe32): Use
__uint32_identity.
[__BYTE_ORDER != __LITTLE_ENDIAN] (be32toh): Likewise.
[__BYTE_ORDER != __LITTLE_ENDIAN] (htobe64): Use
__uint64_identity.
[__BYTE_ORDER != __LITTLE_ENDIAN] (be64toh): Likewise.
* string/Makefile (headers): Add bits/uintn-identity.h.
(tests): Add test-endian-types.
* string/test-endian-types.c: New file.
* inet/Makefile (tests): Add test-hnto-types.
* inet/test-hnto-types.c: New file.
Joseph Myers [Wed, 11 Jan 2017 14:02:23 +0000 (14:02 +0000)]
Fix testsuite build for GCC 7 -Wformat-truncation.
This patch fixes the glibc testsuite build for GCC 7
-Wformat-truncation, newly moved out of -Wformat-length and with some
further warnings that didn't previously appear. Two tests that
previously disabled -Wformat-length are changed to disable
-Wformat-truncation instead; two others are made to disable that
option as well.
Tested (compilation only) with build-many-glibcs.py for aarch64 with
GCC mainline.
* stdio-common/tst-printf.c [__GNUC_PREREQ (7, 0)]: Ignore
-Wformat-truncation instead of -Wformat-length.
* time/tst-strptime2.c (mkbuf) [__GNUC_PREREQ (7, 0)]: Likewise.
* stdio-common/tstdiomisc.c (F): Ignore -Wformat-truncation for
GCC 7.
* wcsmbs/tst-wcstof.c: Include <libc-internal.h>.
(do_test): Ignore -Wformat-truncation for GCC 7.
Joseph Myers [Wed, 11 Jan 2017 13:59:01 +0000 (13:59 +0000)]
Fix ld-address format-truncation error.
With the elf/sotruss-lib.c failure fixed, building 64-bit glibc with
GCC mainline fails with another format-truncation error in
locale/programs/ld-address.c, where 11 bytes are allocated for a
buffer to print a long int value.
This patch changes that code to allocate 21 bytes. Treating this
value as signed is questionable and I don't think large values are
actually useful here, but I think those can be considered as instances
of bug 21036 which I've filed for overflow checks for numeric values
in localedef in general, and don't need to be addressed to fix the
build.
Tested with GCC mainline with compilation for aarch64 with
build-many-glibcs.py, and with glibc testsuite for x86_64 (built with
GCC 6).
(Note that while this fixes the build of 64-bit glibc with GCC
mainline, further fixes will be needed to get the testsuite building
with GCC mainline again.)
* locale/programs/ld-address.c (INT_STR_ELEM): Increase size of
buffer used to print long int value.
Joseph Myers [Wed, 11 Jan 2017 13:57:59 +0000 (13:57 +0000)]
Fix elf/sotruss-lib format-truncation error.
Building 64-bit glibc with GCC mainline fails with:
../elf/sotruss-lib.c: In function 'la_version':
../elf/sotruss-lib.c:91:28: error: '%lu' directive output may be truncated writing between 1 and 20 bytes into a region of size 11 [-Werror=format-truncation=]
snprintf (endp, 12, ".%lu", (unsigned long int) pid);
^~~
../elf/sotruss-lib.c:91:26: note: using the range [1, 18446744073709551615] for directive argument
snprintf (endp, 12, ".%lu", (unsigned long int) pid);
^~~~~~
../elf/sotruss-lib.c:91:6: note: format output between 3 and 22 bytes into a destination of size 12
snprintf (endp, 12, ".%lu", (unsigned long int) pid);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pids from getpid cannot actually be negative, but the compiler doesn't
know this. Other places in this file use (signed) long int for
printing, so this patch makes this place do so as well. Then it
increases the buffer size by one byte to allow for the minus sign that
can't actually occur. It doesn't seem worth using diagnostic pragmas
to save one byte; other place in this file just use a cruder 3 *
sizeof (pid_t) calculation for number of digits.
Tested with GCC mainline with compilation for aarch64 with
build-many-glibcs.py, and with glibc testsuite for x86_64 (built with
GCC 6).
* elf/sotruss-lib.c (init): Increase space allocated for pid by
one byte. Print it with %ld, cast to long int.
Szabolcs Nagy [Tue, 10 Jan 2017 18:31:19 +0000 (16:31 -0200)]
Make build-many-glibcs.py work on python3.2
I used this patch to run the new build script with python3.2, it may be worth
adding this hack if python3.5 is not widespread (might work with older python,
i haven't tested that).
This patch make build-many-glibcs.py work with python 3.2 by
adding fallback implementation to python 3.5 facilities if they
are not present.
Checked building a x86_64-linux-gnu toolchain with python 3.2.
tunables: Avoid getenv calls and disable glibc.malloc.check by default
Builds with --enable-tunables failed on i686 because a call to getenv
got snuck into tunables, which pulled in strncmp. This patch fixes
this build failure by making the glibc.malloc.check check even
simpler. The previous approach was convoluted where the tunable was
disabled using an unsetenv and overwriting the tunable value with
colons. The easier way is to simply mark the tunable as insecure by
default (i.e. won't be read for AT_SECURE programs) and then enabled
only when the /etc/suid-debug file is found.
This also ends up removing a bunch of functions that were specially
reimplemented (strlen, unsetenv) to avoid calling into string
routines.
Tested on x86_64 and i686.
* elf/dl-tunables.c (tunables_unsetenv): Remove function.
(min_strlen): Likewise.
(disable_tunable): Likewise.
(maybe_disable_malloc_check): Rename to
maybe_enable_malloc_check.
(maybe_enable_malloc_check): Enable glibc.malloc.check tunable
if /etc/suid-debug file exists.
(__tunables_init): Update caller.
* elf/dl-tunables.list (glibc.malloc.check): Don't mark as
secure.