This patch fixes what I believe to be a bug in the handling of
R_ARM_IRELATIVE RELA relocations. At present, these are handled the
same as REL relocations: i.e. the addend is loaded from the relocation
address. Most of the time this isn't a problem because RELA relocations
aren't used on ARM (GNU/Linux at least) anyway, but it causes problems
with prelink, which uses RELA on all targets for its conflict table.
(Support for ifunc prelinking requires a prelink patch, not yet posted.)
Anyway, this patch works, though I'm not 100% sure if it is correct: I
notice that this code path received attention last year:
https://sourceware.org/ml/libc-ports/2013-07/msg00000.html
I'm not sure under what circumstances that patch would have had an
effect, nor if my patch conflicts with that case.
No regressions using Mentor's usual glibc cross-testing infrastructure.
[BZ #16888]
* sysdeps/arm/dl-machine.h (elf_machine_rela): Fix R_ARM_IRELATIVE
handling.
This patch increases the minimum Linux kernel version for glibc to
2.6.32, as discussed in the thread starting at
<https://sourceware.org/ml/libc-alpha/2014-01/msg00511.html>.
This patch just does the minimal change to arch_minimum_kernel
settings (and LIBC_LINUX_VERSION, which determines the minimum kernel
headers version, as it doesn't make sense for that to be older than
the minimum kernel that can be used at runtime). Followups would be
expected to do, roughly and not necessarily precisely in this order:
* Remove __LINUX_KERNEL_VERSION checks in kernel-features.h files
where those checks are always true / always false for kernels 2.6.32
and above.
* Otherwise simplify/improve conditionals in those files (for example,
where defining once in the main file then undefining in
architecture-specific files makes things clearer than having lots of
separate definitions of the same macro), possibly fixing in the
process cases where a macro should optimally have been defined for a
given architecture but wasn't. (In the review in preparation for
this version increase I checked what the right conditions should be
for all macros in the main kernel-features.h whose definitions there
would have been affected by the increase - but I only fixed that
subset of the issues found where --enable-kernel=2.6.32 would have
caused a kernel feature to be wrongly assumed to be present, not any
cases where a feature is not assumed but could be assumed.)
* Remove conditionals on __ASSUME_* where they can now be taken to be
always-true, and the definitions when the macros are only used in
Linux-specific files.
* Split more architectures out of the main kernel-features.h (like
ex-ports architectures), once various of the architecture
conditionals there have been eliminated so the new
architecture-specific files are no larger than actually necessary.
Tested x86_64.
2014-03-27 Joseph Myers <joseph@codesourcery.com>
[BZ #9894]
* sysdeps/unix/sysv/linux/configure.ac (LIBC_LINUX_VERSION):
Change to 2.6.32.
(arch_minimum_kernel): Change all 2.6.16 settings to 2.6.32.
* sysdeps/unix/sysv/linux/configure: Regenerated.
* sysdeps/unix/sysv/linux/microblaze/configure.ac: Remove file.
* sysdeps/unix/sysv/linux/microblaze/configure: Likewise.
* sysdeps/unix/sysv/linux/tile/configure.ac: Likewise.
* sysdeps/unix/sysv/linux/tile/configure: Likewise.
* README: Update reference to required Linux kernel version.
* manual/install.texi (Linux): Update reference to required Linux
kernel headers version.
* INSTALL: Regenerated.
The datahead structure has an unused padding field that remains
uninitialized. Valgrind prints out a warning for it on querying a
netgroups entry. This is harmless, but is a potential data leak since
it would result in writing out an uninitialized byte to the cache
file. Besides, this happens only when there is a cache miss, so we're
not adding computation to any fast path.
[Fixes BZ #14308, #12994, #13651]
AF_UNSPEC results in sending two queries in parallel, one for the A
record and the other for the AAAA record. If one of these is a
referral, then the query fails, which is wrong. It should return at
least the one successful response.
The fix has two parts. The first part makes the referral fall back to
the SERVFAIL path, which results in using the successful response.
There is a bug in that path however, due to which the second part is
necessary. The bug here is that if the first response is a failure
and the second succeeds, __libc_res_nsearch does not detect that and
assumes a failure. The case where the first response is a success and
the second fails, works correctly.
This condition is produced by buggy routers, so here's a crude
interposable library that can simulate such a condition. The library
overrides the recvfrom syscall and modifies the header of the packet
received to reproduce this scenario. It has two key variables:
mod_packet and first_error.
The mod_packet variable when set to 0, results in odd packets being
modified to be a referral. When set to 1, even packets are modified
to be a referral.
The first_error causes the first response to be a failure so that a
domain-appended search is performed to test the second part of the
__libc_nsearch fix.
The driver for this fix is a simple getaddrinfo program that does an
AF_UNSPEC query. I have omitted this since it should be easy to
implement.
I have tested this on x86_64.
The interceptor library source:
/* Override recvfrom and modify the header of the first DNS response to make it
a referral and reproduce bz #845218. We have to resort to this ugly hack
because we cannot make bind return the buggy response of a referral for the
AAAA record and an authoritative response for the A record. */
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <stdbool.h>
#include <endian.h>
#include <dlfcn.h>
#include <stdlib.h>
/* Lifted from resolv/arpa/nameser_compat.h. */
typedef struct {
unsigned id :16; /*%< query identification number */
#if BYTE_ORDER == BIG_ENDIAN
/* fields in third byte */
unsigned qr: 1; /*%< response flag */
unsigned opcode: 4; /*%< purpose of message */
unsigned aa: 1; /*%< authoritive answer */
unsigned tc: 1; /*%< truncated message */
unsigned rd: 1; /*%< recursion desired */
/* fields
* in
* fourth
* byte
* */
unsigned ra: 1; /*%< recursion available */
unsigned unused :1; /*%< unused bits (MBZ as of 4.9.3a3) */
unsigned ad: 1; /*%< authentic data from named */
unsigned cd: 1; /*%< checking disabled by resolver */
unsigned rcode :4; /*%< response code */
#endif
#if BYTE_ORDER == LITTLE_ENDIAN || BYTE_ORDER == PDP_ENDIAN
/* fields
* in
* third
* byte
* */
unsigned rd :1; /*%< recursion desired */
unsigned tc :1; /*%< truncated message */
unsigned aa :1; /*%< authoritive answer */
unsigned opcode :4; /*%< purpose of message */
unsigned qr :1; /*%< response flag */
/* fields
* in
* fourth
* byte
* */
unsigned rcode :4; /*%< response code */
unsigned cd: 1; /*%< checking disabled by resolver */
unsigned ad: 1; /*%< authentic data from named */
unsigned unused :1; /*%< unused bits (MBZ as of 4.9.3a3) */
unsigned ra :1; /*%< recursion available */
#endif
/* remaining
* bytes
* */
unsigned qdcount :16; /*%< number of question entries */
unsigned ancount :16; /*%< number of answer entries */
unsigned nscount :16; /*%< number of authority entries */
unsigned arcount :16; /*%< number of resource entries */
} HEADER;
static int done = 0;
/* Packets to modify. 0 for the odd packets and 1 for even packets. */
static const int mod_packet = 0;
/* Set to true if the first request should result in an error, resulting in a
search query. */
static bool first_error = true;
static ssize_t (*real_recvfrom) (int sockfd, void *buf, size_t len, int flags,
struct sockaddr *src_addr, socklen_t *addrlen);
void
__attribute__ ((constructor))
init (void)
{
real_recvfrom = dlsym (RTLD_NEXT, "recvfrom");
if (real_recvfrom == NULL)
{
printf ("Failed to get reference to recvfrom: %s\n", dlerror ());
printf ("Cannot simulate test\n");
abort ();
}
}
/* Modify the second packet that we receive to set the header in a manner as to
reproduce BZ #845218. */
static void
mod_buf (HEADER *h, int port)
{
if (done % 2 == mod_packet || (first_error && done == 1))
{
printf ("(Modifying header)");
if (first_error && done == 1)
h->rcode = 3;
else
h->rcode = 0; /* NOERROR == 0. */
h->ancount = 0;
h->aa = 0;
h->ra = 0;
h->arcount = 0;
}
done++;
}
ssize_t
recvfrom (int sockfd, void *buf, size_t len, int flags,
struct sockaddr *src_addr, socklen_t *addrlen)
{
ssize_t ret = real_recvfrom (sockfd, buf, len, flags, src_addr, addrlen);
int port = htons (((struct sockaddr_in *) src_addr)->sin_port);
struct in_addr addr = ((struct sockaddr_in *) src_addr)->sin_addr;
const char *host = inet_ntoa (addr);
printf ("\n*** From %s:%d: ", host, port);
mod_buf (buf, port);
printf ("returned %zd\n", ret);
return ret;
}
The current implementation of setcontext uses rt_sigreturn to restore
the contents of registers. This contrasts with the way most other
architectures implement setcontext:
powerpc64, mips, tile:
Call rt_sigreturn if context was created by a call to a signal handler,
otherwise restore in user code.
powerpc32:
Call swapcontext system call and don't call sigreturn or rt_sigreturn.
x86_64, sparc, hppa, sh, ia64, m68k, s390, arm:
Only support restoring "synchronous" contexts, that is contexts
created by getcontext, and restoring in user code and don't call
sigreturn or rt_sigreturn.
alpha:
Call sigreturn (but not rt_sigreturn) in all cases to do the restore.
The text of the setcontext manpage suggests that the requirement to be
able to restore a signal handler created context has been dropped from
SUSv2:
If the context was obtained by a call to a signal handler, then old
standard text says that "program execution continues with the program
instruction following the instruction interrupted by the signal".
However, this sentence was removed in SUSv2, and the present verdict
is "the result is unspecified".
Implementing setcontext by calling rt_sigreturn unconditionally causes
problems when used with sigaltstack as in BZ #16629. On this basis it
seems that aarch64 is broken and that new ports should only support
restoring contexts created with getcontext and do not need to call
rt_sigreturn at all.
This patch re-implements the aarch64 setcontext function to restore
the context in user code in a similar manner to x86_64 and other ports.
ChangeLog:
2014-04-17 Will Newton <will.newton@linaro.org>
[BZ #16629]
* sysdeps/unix/sysv/linux/aarch64/setcontext.S (__setcontext):
Re-implement to restore registers in user code and avoid
rt_sigreturn system call.
We initialize _r_debug for static binaries to allows debug
agents to treat static binaries a little more like dyanmic
ones. This simplifies the work a debug agent has to do to
access TLS in a static binary via libthread_db.
Tested on x86_64.
See:
https://sourceware.org/ml/libc-alpha/2014-04/msg00183.html
[BZ #16831]
* csu/libc-start.c (LIBC_START_MAIN) [!SHARED]: Call
_dl_debug_initialize.
pathconf(_PC_NAME_MAX) was implemented on top of statfs(). The 32bit
version therefore fails EOVERFLOW if the filesystem blockcount is
sufficiently large.
Most pathconf() queries use statvfs64(), which avoids this issue. This
patch modifies pathconf(_PC_NAME_MAX) to do likewise.
This patch fixes the powerpc32 optimized nearbyint/nearbyintf bogus
results for FE_DOWNWARD rounding mode. This is due wrong instructions
sequence used in the rounding calculation (two subtractions instead of
adition and a subtraction).
Fixes BZ#16815.
This patch fixes incorrect results from catan and catanh of certain
special inputs in round-downward mode (bug 16799), and incorrect
results of __ieee754_logf (+/-0) in round-downward mode (bug 16800)
that show up through catan/catanh when tested in all rounding modes,
but not directly in the testing for logf because the bug gets hidden
by the wrappers.
Both bugs involve a zero that should be +0 being -0 instead: one
computed as (1-x)*(1+x) in the catan/catanh case, and one as (x-x) in
the logf case. The fixes ensure positive zero is used. Testing of
catan and catanh in all rounding modes is duly enabled.
I expect there are various other bugs in special cases in __ieee754_*
functions that are normally hidden by the wrappers but would show up
for testing with -lieee (or in future with -fno-math-errno if we
replace -lieee and _LIB_VERSION with compile-time redirection to new
*_noerrno symbol names).
Tested x86_64 and x86 and ulps updated accordingly.
[BZ #16799]
[BZ #16800]
* math/s_catan.c (__catan): Avoid passing -0 denominator to atan2
with 0 numerator.
* math/s_catanf.c (__catanf): Likewise.
* math/s_catanh.c (__catanh): Likewise.
* math/s_catanhf.c (__catanhf): Likewise.
* math/s_catanhl.c (__catanhl): Likewise.
* math/s_catanl.c (__catanl): Likewise.
* sysdeps/ieee754/flt-32/e_logf.c (__ieee754_logf): Always divide
by positive zero when computing -Inf result.
* math/libm-test.inc (catan_test): Use ALL_RM_TEST.
(catanh_test): Likewise.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
This patch fixes bug 16789, incorrect sign of (real part) zero result
from clog and clog10 in round-downward mode, arising from that real
part being computed as 0 - 0. To ensure that an underflow exception
occurred, the code used an underflowing value (the next term in the
series for log1p) in arithmetic computing the real part of the result,
yielding the problematic 0 - 0 computation in some cases even when the
mathematical result would be small but positive. The patch changes
this code to use the math_force_eval approach to ensuring that an
underflowing computation actually occurs. Tests of clog and clog10
are enabled in all rounding modes.
Tested x86_64 and x86 and ulps updated accordingly.
[BZ #16789]
* math/s_clog.c (__clog): Use math_force_eval to ensure underflow
instead of using underflowing value in computing result.
* math/s_clog10.c (__clog10): Likewise.
* math/s_clog10f.c (__clog10f): Likewise.
* math/s_clog10l.c (__clog10l): Likewise.
* math/s_clogf.c (__clogf): Likewise.
* math/s_clogl.c (__clogl): Likewise.
* math/libm-test.inc (clog_test): Use ALL_RM_TEST.
(clog10_test): Likewise.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
Fix for values near a power of two, and some tidies.
[BZ #16739]
* sysdeps/ieee754/ldbl-128ibm/s_nextafterl.c (__nextafterl): Correct
output when value is near a power of two. Use int64_t for lx and
remove casts. Use decimal rather than hex exponent constants.
Don't use long double multiplication when double will suffice.
* math/libm-test.inc (nextafter_test_data): Add tests.
* NEWS: Add 16739 and 16786 to bug list.
This patch fixes the default mode of scalb to set errno (bugs 6803 and
6804).
Previously, the _LIB_VERSION == _SVID_ mode would set errno but only
in some relevant cases, and with various peculiarities (such as errno
setting when an exact infinity or zero result arises with an argument
to scalb being an infinity). This patch leaves this mode
bug-compatible, while making the default mode set errno in accordance
with normal practice (so an exact infinity from an infinite argument
is not an error, and nor is an exact zero result). gen-libm-test.pl
is taught new notation such as ERRNO_PLUS_OFLOW to facilitate writing
the tests of errno setting for underflow / overflow in libm-test.inc.
Note that bug 6803 also covers scalbn and scalbln, but this patch only
addresses the scalb parts of that bug (along with the whole of bug
6804).
Tested x86_64 and x86.
[BZ #6803]
[BZ #6804]
* math/w_scalb.c (__scalb): For non-SVID mode, check result and
set errno as appropriate.
* math/w_scalbf.c (__scalbf): Likewise.
* math/w_scalbl.c (__scalbl): Likewise.
* math/gen-libm-test.pl (parse_args): Handle ERRNO_PLUS_OFLOW,
ERRNO_MINUS_OFLOW, ERRNO_PLUS_UFLOW and ERRNO_MINUS_UFLOW.
* math/libm-test.inc (scalb_test_data): Add errno expectations.
Add more NaN tests.
This patch fixes bug 16349, missing errno setting for atan2 underflow,
by adding appropriate checks to the existing wrappers. (As in other
cases, the __kernel_standard support for calling matherr is considered
to be for existing code expecting existing rules for what's considered
an error, even if those don't correspond to a general logical scheme
for what counts as what kind of error, so __set_errno calls are added
directly without any changes to __kernel_standard.)
Tested x86_64 and x86.
[BZ #16349]
* math/w_atan2.c: Include <errno.h>.
(__atan2): Set errno for result underflowing to zero.
* math/w_atan2f.c: Include <errno.h>.
(__atan2f): Set errno for result underflowing to zero.
* math/w_atan2l.c: Include <errno.h>.
(__atan2l): Set errno for result underflowing to zero.
* math/auto-libm-test-in: Don't allow missing errno for some atan2
tests.
* math/auto-libm-test-out: Regenerated.
Continuing the fixes for __ASSUME_* issues in preparation for moving
to a 2.6.32 minimum kernel version, this *untested* patch fixes bug
16648, the definition of __ASSUME_ATFCTS meaning that the futimesat
syscall is assumed for all MicroBlaze kernels despite not being
present until 2.6.33.
__ASSUME_ATFCTS controls conditionals relating to a lot of different
syscalls in Linux-specific code (fstatat64 faccessat fchmodat fchownat
futimesat newfstatat linkat mkdirat openat readlinkat renameat
symlinkat unlinkat mknodat), where whether newfstatat fstatat64
futimesat are used depends on the architecture, as well as controlling
whether openat64_not_cancel_3 is expected to work in
sysdeps/posix/getcwd.c. The assumptions are all OK as of 2.6.32
except for this MicroBlaze case, and it's generally desirable to get
rid of as many of the __ASSUME_ATFCTS conditionals as possible, to
simplify the code (the fallbacks include potential unbounded dynamic
stack allocations). Thus, rather than the simplest approach of
undefining __ASSUME_ATFCTS for older kernels on MicroBlaze, this patch
takes the approach of using the linux-generic implementation of
futimesat for MicroBlaze kernels before 2.6.33 (all such kernels have
the utimensat syscall).
[BZ #16648]
* sysdeps/unix/sysv/linux/microblaze/kernel-features.h
[__LINUX_KERNEL_VERSION >= 0x020621] (__ASSUME_FUTIMESAT): Define.
* sysdeps/unix/sysv/linux/microblaze/futimesat.c: New file.
This patch fixes bug 16770, spurious "invalid" exceptions from scalb
when testing whether the second argument is an integer, by inserting
appropriate range checks to determine whether a cast to int is safe.
(Note that invalid_fn is a function that handles both nonintegers and
large integers, distinguishing them reliably using functions such as
__rint; note also that there are no issues with scalb needing to avoid
spurious "inexact" exceptions - it's an old-POSIX XSI function, not a
standard C function bound to an IEEE 754 operation - although the
return value is still fully determined.)
Tested x86_64 and x86.
[BZ #16770]
* math/e_scalb.c (__ieee754_scalb): Check second argument is not
too large before casting to int.
* math/e_scalbf.c (__ieee754_scalbf): Likewise.
* math/e_scalbl.c (__ieee754_scalbl): Likewise.
* math/libm-test.inc (scalb_test_data): Add more tests.
This patch fixes the imaginary part of clog10 (-0 +/- 0i), which
should be +/-pi / log(10) by analogy with clog (the functions were
wrongly returning a result with imaginary part +/-pi, same as for
clog, and the tests matched the incorrect result, though both
functions and tests were correct for the similar case of clog10 (-inf
+/- 0i)). Tested x86_64 and x86.
[BZ #16362]
* math/s_clog10.c (M_PI_LOG10E): New macro.
(__clog10): Use M_PI_LOG10E instead of M_PI when real and
imaginary parts are 0.
* math/s_clog10f.c (M_PI_LOG10Ef): New macro.
(__clog10f): Use M_PI_LOG10Ef instead of M_PI when real and
imaginary parts are 0.
* math/s_clog10l.c (M_PI_LOG10El): New macro.
(__clog10l): Use M_PI_LOG10El instead of M_PIl when real and
imaginary parts are 0.
* math/libm-test.inc (clog10_test_data): Update expected results
for when real and imaginary parts are 0.
This patch fixes bug 16348, spurious underflows from x86/x86_64 expl
on arguments close to 0. These implementations effectively use expm1
(on the fractional part of the argument) internally, so resulting in
spurious underflows when the result is very close to 1. For arguments
small enough that the round-to-nearest correct result is 1, this patch
uses 1+x instead.
These implementations are also used for exp10l and so the patch fixes
similar issues there (the 0x1p-67 threshold being small enough to be
correct for exp10l as well as expl). But because of spurious
underflows in other exp10 implementations (bug 16560), the tests
aren't added for exp10 at this point - they can be added when the
other exp10 parts of that bug are fixed.
Tested x86_64 and x86; no ulps updates needed.
[BZ #16348]
* sysdeps/i386/fpu/e_expl.S (IEEE754_EXPL) [!USE_AS_EXPM1L]: Use
1+x for argument with exponent below -67.
* sysdeps/x86_64/fpu/e_expl.S (IEEE754_EXPL) [!USE_AS_EXPM1L]:
Likewise.
* math/auto-libm-test-in: Add more tests of exp.
* math/auto-libm-test-out: Regenerated.
getnetgrent is supposed to return NULL for values that are wildcards
in the (host, user, domain) triplet. This works correctly with nscd
disabled, but with it enabled, it returns a blank ("") instead of a
NULL. This is easily seen with the output of `getent netgroup foonet`
for a netgroup foonet defined as follows in /etc/netgroup:
foonet (,foo,)
The output with nscd disabled is:
foonet ( ,foo,)
while with nscd enabled, it is:
foonet (,foo,)
The extra space with nscd disabled is due to the fact that `getent
netgroup` adds it if the return value from getnetgrent is NULL for
either host or user.
Calls to stpcpy from nscd netgroups code will have overlapping source
and destination when all three values in the returned triplet are
non-NULL and in the expected (host,user,domain) order. This is seen
in valgrind as:
==3181== Source and destination overlap in stpcpy(0x19973b48, 0x19973b48)
==3181== at 0x4C2F30A: stpcpy (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3181== by 0x12567A: addgetnetgrentX (string3.h:111)
==3181== by 0x12722D: addgetnetgrent (netgroupcache.c:665)
==3181== by 0x11114C: nscd_run_worker (connections.c:1338)
==3181== by 0x4E3C102: start_thread (pthread_create.c:309)
==3181== by 0x59B81AC: clone (clone.S:111)
==3181==
Fix this by using memmove instead of stpcpy.
nscd works correctly when the request in innetgr is a wildcard,
i.e. when one or more of host, user or domain parameters is NULL.
However, it does not work when the the triplet in the netgroup
definition has a wildcard. This is easy to reproduce for a triplet
defined as follows:
foonet (,foo,)
Here, an innetgr call that looks like this:
innetgr ("foonet", "foohost", "foo", NULL);
should succeed and so should:
innetgr ("foonet", NULL, "foo", "foodomain");
It does succeed with nscd disabled, but not with nscd enabled. This
fix adds this additional check for all three parts of the triplet so
that it gives the correct result.
[BZ #16758]
* nscd/netgroupcache.c (addinnetgrX): Succeed if triplet has
blank values.
Bug 16198 is x86_64 fegetenv wrongly masking exceptions for which
traps are enabled, because that's a side-effect of the fnstenv
instruction. This patch fixes it to use fldenv immediately after
fnstenv, like the i386 version. Tested x86_64 and x86.
[BZ #16198]
* sysdeps/x86_64/fpu/fegetenv.c (fegetenv): Use fldenv after
fnstenv.
* math/test-fenv-preserve.c: New file.
* math/Makefile (tests): Add test-fenv-preserve.
gen-auto-libm-tests presently allows but does not require underflow
exceptions for results with magnitude in the range (greatest
subnormal, least normal].
In some cases, the magnitude of the exact result is very slightly
above the least normal, but rounding in the implementation results in
it effectively computing an infinite-precision result that is slightly
below the least normal, so raising an underflow exception. This is in
accordance with the documented accuracy goals, but results in
testsuite failures.
This patch changes the logic to allow underflows when the mathematical
result is up to 0.5ulp above the least normal (so in any case where
the round-to-nearest result is the least normal). Ideally underflows
in all these cases would be accepted only when an underflow with the
actual result is consistent with the rounding mode (in FE_TOWARDZERO
mode, a return value of the least normal implies that the
infinite-precision result did not underflow so there should be no
underflow exception, for example), so as to match the documented goals
more precisely - whereas at present the tests for exceptions are
completely independent of the tests of the returned values. (The same
applies to overflow exceptions as well - they too should be checked
for consistency with the result, as in FE_TOWARDZERO mode a result
1ulp below the largest finite value should be inconsistent with an
overflow exception and cause a failure with overflow rather than
simply being considered a 1ulp error when overflow is expected.) But
the present patch at least deals with the cases causing spurious
failures so that (a) certain existing tests no longer need to be
marked as having spurious exceptions (such markings in
auto-libm-test-in end up applying to more cases than just those they
are needed for) and (b) log1p can be tested in all rounding modes
without introducing more such failures. This patch duly moves tests
of log1p to ALL_RM_TEST.
Tested x86_64 and x86 and ulps updated accordingly.
[BZ #16357]
[BZ #16599]
* math/gen-auto-libm-tests.c (fp_format_desc): Add field
min_plus_half.
(fp_formats): Update initializers.
(init_fp_formats): Initialize new field.
(output_for_one_input_case): Allow underflow for results up to
min_plus_half.
* math/libm-test.inc (log1p_test): Use ALL_RM_TEST.
* math/auto-libm-test-in: Don't mark some underflows from asin and
atanh as spurious.
* math/auto-libm-test-out: Regenerated.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
An application that erroneously tries to repeatedly dlopen("a.out", ...)
may hit assertion failure:
Inconsistency detected by ld.so: dl-tls.c: 474: _dl_allocate_tls_init:
Assertion `listp != ((void *)0)' failed!
dlopen() actually fails with "./a.out: cannot dynamically load executable",
but it does so after incrementing dl_tls_max_dtv_idx.
Once we run out of TLS_SLOTINFO_SURPLUS (62), we exit with above assertion
failure.
2014-03-24 Paul Pluzhnikov <ppluzhnikov@google.com>
[BZ #16634]
* elf/dl-load.c (open_verify): Add mode parameter.
Error early when ET_EXEC and mode does not have __RTLD_OPENEXEC.
(open_path): Change from boolean 'secure' to complete flag 'mode'
(_dl_map_object): Adjust.
* elf/Makefile (tests): Add tst-dlopen-aout.
* elf/tst-dlopen-aout.c: New test.
This fixes a bug in the way the results from __nscd_getai are collected:
for every returned result a new entry is first added to the
gaih_addrtuple list, but if that result doesn't match the request this
entry remains uninitialized. So for this non-matching result an extra
result with uninitialized content is returned.
To reproduce (with nscd running):
$ getent ahostsv4 localhost
127.0.0.1 STREAM localhost
127.0.0.1 DGRAM
127.0.0.1 RAW
(null) STREAM
(null) DGRAM
(null) RAW
To reproduce:
# ip li add name dummy0 type dummy
# site_id=$(head -c6 /dev/urandom | od -tx2 -An | tr ' ' ':')
# for ((i = 0; i < 65536; i++)) do
> ip ad ad $(printf fd80$site_id::%04x $i)/128 dev dummy0
> done
# (ulimit -s 900; getent ahosts localhost)
# ip li de dummy0
The dbl-64 version of exp needs round-to-nearest mode for its internal
computations, but that has the consequence of inappropriate
overflowing and underflowing results in other rounding modes. This
patch fixes this by recomputing the relevant results in cases where
the round-to-nearest result overflows to infinity or underflows to
zero (most of the diffs are actually just consequent reindentation).
Tests are enabled in all rounding modes for complex functions using
exp - but not for cexp because it turns out there are bugs causing
spurious underflows for cexp for some tests, which will need to be
fixed separately (I suspect ccos ccosh csin csinh ctan ctanh have
similar bugs, just not shown by the present set of test inputs).
Tested x86_64 and x86 and ulps updated accordingly.
[BZ #16284]
* sysdeps/ieee754/dbl-64/e_exp.c (__ieee754_exp): Use original
rounding mode to recompute results that overflow to infinity or
underflow to zero.
* math/auto-libm-test-in: Don't mark tests as expected to fail for
bug 16284.
* math/auto-libm-test-out: Regenerated.
* math/libm-test.inc (ccos_test): Use ALL_RM_TEST.
(ccosh_test): Likewise.
(csin_test_data): Use plus_oflow.
(csin_test): Use ALL_RM_TEST.
(csinh_test_data): Use plus_oflow.
(csinh_test): Use ALL_RM_TEST.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
According to ISO C Annex F, log (1) should be +0 in all rounding
modes, but some implementations in glibc wrongly return -0 in
round-downward mode (mapping to log1p (x - 1) is problematic because 1
- 1 is -0 in round-downward mode, and log1p (-0) is -0). This patch
fixes this. (It helps with some implementations of other functions
such as acosh, log2 and log10 that call out to log, but not enough to
enable all-rounding-modes testing for those functions without further
fixes to other implementations of them.)
Tested x86_64 and x86 and ulps updated accordingly, and did spot tests
for mips64 for the ldbl-128 fix, and i586 for the sysdeps/i386/fpu
implementations shadowed by those in sysdeps/i386/i686/fpu.
[BZ #16731]
* sysdeps/i386/fpu/e_log.S (__ieee754_log): Take absolute value
when x - 1 is zero.
* sysdeps/i386/fpu/e_logf.S (__ieee754_logf): Likewise.
* sysdeps/i386/fpu/e_logl.S (__ieee754_logl): Likewise.
* sysdeps/i386/i686/fpu/e_logl.S (__ieee754_logl): Likewise.
* sysdeps/ieee754/dbl-64/e_log.c (__ieee754_log): Return +0 when
argument is 1.
* sysdeps/ieee754/ldbl-128/e_logl.c (__ieee754_logl): Likewise.
* sysdeps/x86_64/fpu/e_logl.S: Take absolute value when x - 1 is
zero.
* math/libm-test.inc (log_test): Use ALL_RM_TEST.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
Reviewing (for all architectures, with a baseline kernel version of
2.6.32) the kernel support for features for which __ASSUME_* macros
would be affected by a move to 2.6.32 as minimum kernel version showed
up that __ASSUME_PREADV and __ASSUME_PWRITEV were wrongly defined for
MicroBlaze (despite the corresponding syscall table entries not being
wired up in the kernel) and Alpha for 2.6.30 and above (although the
support on Alpha was added in 2.6.33). This patch makes the
kernel-features.h files undefine those macros for appropriate
versions.
[BZ #16649]
* sysdeps/unix/sysv/linux/alpha/kernel-features.h
[__LINUX_KERNEL_VERSION < 0x020621] (__ASSUME_PREADV): Undefine.
[__LINUX_KERNEL_VERSION < 0x020621] (__ASSUME_PWRITEV): Likewise.
* sysdeps/unix/sysv/linux/microblaze/kernel-features.h
(__ASSUME_PREADV): Undefine.
(__ASSUME_PWRITEV): Likewise.
The ftell implementation was made conservative to ensure that
incorrectly cached offsets never affect it. However, this causes
problems for append mode when a file stream is rewound. Additionally,
the 'clever' trick of using stat to get position for append mode files
caused more problems than it solved and broke old behavior. I have
described the various problems that it caused and then finally the
solution.
For a and a+ mode files, rewinding the stream should result in ftell
returning 0 as the offset, but the stat() trick caused it to
(incorrectly) always return the end of file. Now I couldn't find
anything in POSIX that specifies the stream position after rewind()
for a file opened in 'a' mode, but for 'a+' mode it should be set to
0. For 'a' mode too, it probably makes sense to keep it set to 0 in
the interest of retaining old behavior.
The initial file position for append mode files is implementation
defined, so the implementation could either retain the current file
position or move the position to the end of file. The earlier ftell
implementation would move the offset to end of file for append-only
mode, but retain the old offset for a+ mode. It would also cache the
offset (this detail is important). My patch broke this and would set
the initial position to end of file for both append modes, thus
breaking old behavior. I was ignorant enough to write an incorrect
test case for it too.
The Change:
I have now brought back the behavior of seeking to end of file for
append-only streams, but with a slight difference. I don't cache the
offset though, since we would want ftell to query the current file
position through lseek while the stream is not active. Since the
offset is moved to the end of file, we can rely on the file position
reported by lseek and we don't need to resort to the stat() nonsense.
Finally, the cache is always reliable, except when there are unflished
writes in an append mode stream (i.e. both a and a+). In the latter
case, it is safe to just do an lseek to SEEK_END. The value can be
safely cached too, since the file handle is already active at this
point. Incidentally, this is the only state change we affect in the
file handle (apart from taking locks of course).
I have also updated the test case to correct my impression of the
initial file position for a+ streams to the initial behavior. I have
verified that this does not break any existing tests in the testsuite
and also passes with the new tests.
This patch is an updated version of
<https://sourceware.org/ml/libc-alpha/2014-01/msg00198.html> and
<https://sourceware.org/ml/libc-alpha/2014-03/msg00180.html>.
Normal practice for software testsuites is that rather than
terminating immediately when a test fails, they continue running and
report at the end on how many tests passed or failed.
The principle behind the glibc testsuite stopping on failure was
probably that the expected state is no failures and so any failure
indicates a problem such as miscompilation. In practice, while this
is fairly close to true for native testing on x86_64 and x86 (kernel
bugs and race conditions can still cause intermittent failures), it's
less likely to be the case on other platforms, and so people testing
glibc run the testsuite with "make -k" and then examine the logs to
determine whether the failures are what they expect to fail on that
platform, possibly with some automation for the comparison.
This patch switches the glibc testsuite to the normal convention of
not stopping on failure - unless you use stop-on-test-failure=y, in
which case it behaves essentially as it did before (and does not
generate overall test summaries on failure). Instead, the summary
tests.sum may contain tests that FAILed. At the end of the test run,
any FAIL or ERROR lines from tests.sum are printed, and then it exits
with error status if there were any such lines. In addition, build
failures will also cause the test run to stop - this has the
justification that those *do* indicate serious problems that should be
promptly fixed and aren't generally hard to fix (but apart from that,
avoiding the build stopping on those failures seems harder).
Note that unlike the previous patches in this series, this *does*
require people with automation around testing glibc to change their
processes - either to start using tests.sum / xtests.sum to track
failures and compare them with expectations (with or without also
using "make -k" and examining "make" logs to identify build failures),
or else to use stop-on-test-failure=y and ignore the new tests.sum /
xtests.sum mechanism. (If all you check is the exit status from "make
check", no changes are needed unless you want to avoid test runs
continuing after the first failure.)
Tested x86_64.
* scripts/evaluate-test.sh: Handle fourth argument to determine
whether test run should stop on failure.
* Makeconfig (stop-on-test-failure): New variable.
(evaluate-test): Pass fourth argument to evaluate-test.sh based on
$(stop-on-test-failure).
* Makefile (tests): Give a summary of results from testing and
exit with failure status if they include an ERROR or FAIL.
(xtests): Likewise.
* manual/install.texi (Configuring and compiling): Mention
stop-on-test-failure=y.
* INSTALL: Regenerated.
The roundl assembly implementation
(sysdeps/powerpc/powerpc64/fpu/s_roundl.S)
returns wrong results for some inputs where first double is a exact
integer and the precision is determined by second long double.
Checking on implementation comments and history, I am very confident the
assembly implementation was based on a version before commit
5c68d40169 that fixes BZ#2423 (Errors in
long double (ldbl-128ibm) rounding functions in glibc-2.4).
By just removing the implementation and make the build select
sysdeps/ieee754/ldbl-128ibm/s_roundl.c instead fixes the failing math.
This fixes 16707.
The nearbyintl assembly implementation
(sysdeps/powerpc/powerpc64/fpu/s_nearbyintl.S)
returns wrong results for some inputs where first double is a exact
integer and the precision is determined by second long double.
Checking on implementation comments and history, I am very confident the
assembly implementation was based on a version before commit
5c68d40169 that fixes BZ#2423 (Errors in
long double (ldbl-128ibm) rounding functions in glibc-2.4).
By just removing the implementation and make the build select
sysdeps/ieee754/ldbl-128ibm/s_nearbyintl.c instead fixes the failing
math.
Fixes BZ#16706.
The ceill assembly implementation (sysdeps/powerpc/powerpc64/fpu/s_ceill.S)
returns wrong results for some inputs where first double is a exact
integer and the precision is determined by second long double.
Checking on implementation comments and history, I am very confident the
assembly implementation was based on a version before commit
5c68d40169 that fixes BZ#2423 (Errors in
long double (ldbl-128ibm) rounding functions in glibc-2.4).
By just removing the implementation and make the build select
sysdeps/ieee754/ldbl-128ibm/s_ceill.c instead fixes the failing math.
Fixes BZ#16701.
Reviewing (for all architectures, with a baseline kernel version of
2.6.32) the kernel support for features for which __ASSUME_* macros
would be affected by a move to 2.6.32 as minimum kernel version showed
up that __ASSUME_PSELECT was wrongly defined for MicroBlaze, despite
the corresponding syscall table entry not being wired up in the
MicroBlaze kernel.
This patch makes the MicroBlaze kernel-features.h undefine
__ASSUME_PSELECT. I'd also encourage wiring it up in the kernel (so
you can then make this #undef conditional, and eventually obsolete
once a recent-enough kernel is required). I suspect it wasn't wired
up because of the mistaken comment in asm/unistd.h "obsolete ->
sys_pselect7" (there is no such syscall as pselect7).
[BZ #16642]
* sysdeps/unix/sysv/linux/microblaze/kernel-features.h
(__ASSUME_PSELECT): Undefine.
This patch fixes an issue for powerpc32-fpu static build which fails
with an 'bzero' undefined reference. This patch adds bzero ifunc selector
for static builds and fixes the '__bzero_ppc' reference to default
memset symbol (since static memset build does not provide ifunc
selector).
Fixes BZ#16689.
The buffer to query netgroup entries is allocated sufficient space for
the netgroup entries and the key to be appended at the end, but it
sends in an incorrect available length to the NSS netgroup query
functions, resulting in overflow of the buffer in some special cases.
The fix here is to factor in the key length when sending the available
buffer and buffer length to the query functions.
