This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: linknamespace failures
- From: Chris Metcalf <cmetcalf at ezchip dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Sun, 21 Dec 2014 16:07:05 -0500
- Subject: Re: linknamespace failures
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp dot mailfrom=cmetcalf at ezchip dot com;
- References: <5494F35F dot 2000107 at ezchip dot com> <alpine dot DEB dot 2 dot 10 dot 1412201107240 dot 20593 at digraph dot polyomino dot org dot uk>
On 12/20/2014 6:11 AM, Joseph Myers wrote:
The vast bulk of these are XFAILed in conform/Makefile. You need to
investigate why the XFAILs there are ineffective for you.
Yes, I think the strstr -> strnlen bug that I fixed caused a lot of
tests to fail, and when I investigated the .out files, I saw other things,
that perhaps would have been suppressed otherwise? Not exactly clear,
but in any case, rerunning make check after that fix was in, the number
of FAILs reduced dramatically:
FAIL: conform/ISO/math.h/linknamespace
FAIL: conform/POSIX/math.h/linknamespace
FAIL: conform/UNIX98/math.h/linknamespace
FAIL: conform/UNIX98/strings.h/linknamespace
FAIL: conform/XOPEN2K/strings.h/linknamespace
FAIL: conform/XOPEN2K8/strings.h/linknamespace
FAIL: conform/XPG3/math.h/linknamespace
FAIL: conform/XPG4/math.h/linknamespace
FAIL: conform/XPG4/strings.h/linknamespace
The strings.h problem is something I understand (ffs vs ffsll); patch to follow.
Looking at the math.h problem, it seems to be that SET_RESTORE_ROUND_53BIT
in sysdeps/ieee754/dbl-64/s_sin.c (for example) calls through to feupdateenv()
and other similar routines:
[initial] __sqrt -> [libm.a(w_sqrt.o)] __ieee754_sqrt -> [libm.a(e_sqrt.o)] fegetround
[initial] __sqrt -> [libm.a(w_sqrt.o)] __ieee754_sqrt -> [libm.a(e_sqrt.o)] fesetenv
[initial] __cos -> [libm.a(s_sin.o)] feupdateenv
[initial] __remainder -> [libm.a(w_remainder.o)] __ieee754_remainder -> [libm.a(e_remainder.o)] fegetenv
[initial] __asinh -> [libm.a(s_asinh.o)] __ieee754_sqrt -> [libm.a(e_sqrt.o)] fegetround
[initial] __remainder -> [libm.a(w_remainder.o)] __ieee754_remainder -> [libm.a(e_remainder.o)] fesetenv
On tile we use the no-op version in math/feupdateenv.c, but surely we should be
calling these routines with the __feupdateenv entry point names?
Finally, in conform/{XPG[34],XOPEN2K}/math.h/linknamespace.out, we see:
[initial] j0 -> [libm.a(w_j0.o)] j0l
[initial] j1 -> [libm.a(w_j1.o)] j1l
[initial] jn -> [libm.a(w_jn.o)] jnl
[initial] j0 -> [libm.a(w_j0.o)] y0l
[initial] j1 -> [libm.a(w_j1.o)] y1l
[initial] jn -> [libm.a(w_jn.o)] ynl
Should, e.g., the strong_alias (j0, j0l) in math/w_j0.c be a weak_alias?
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com