This is the mail archive of the
mailing list for the glibc project.
Re: linknamespace failures
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Chris Metcalf <cmetcalf at ezchip dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Mon, 22 Dec 2014 13:06:50 +0000
- Subject: Re: linknamespace failures
- Authentication-results: sourceware.org; auth=none
- 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> <54973679 dot 2020901 at ezchip dot com>
On Sun, 21 Dec 2014, Chris Metcalf wrote:
> 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,
Remember filing bugs in Bugzilla when fixing anything that would have been
user-visible in a release. That generally applies to bugs shown up by
linknamespace test failures, unless the bug itself is new since the last
release (not just the tests being new).
> The strings.h problem is something I understand (ffs vs ffsll); patch to
Again, remember filing bugs in Bugzilla (appropriately marked as
architecture-specific, or specific to some condition that's not a
particular architecture if applicable).
> On tile we use the no-op version in math/feupdateenv.c, but surely we should
> calling these routines with the __feupdateenv entry point names?
See for example
<https://sourceware.org/ml/libc-alpha/2014-12/msg00749.html>, for which
I'm hoping for a sanity check, addressing such issues for feraiseexcept.
Yes, in such cases the __fe* entry point needs to be called. But note:
(a) As with all such bugs, file a bug in Bugzilla first if working on a
fix. For most of these the relevant condition is probably not having the
inline libc_fe* functions (but for fegetround as called from e_sqrt.c,
there is no such inline function anyway).
(b) Not all architectures may have such an entry point; or, if they do,
the fe* function may be a strong alias rather than a weak alias. So you
need to go through all architectures ensuring they have such an entry
point with fe* as a weak alias.
(c) Then the __fe* function needs libm_hidden_proto / libm_hidden_def so
the compiler knows the calls are within the same shared library.
(d) If there are macro or inline function definitions of fe* that get used
when building glibc, corresponding macro or inline functions of __fe* will
be needed to avoid pessimization.
(e) In some cases, there are existing __fe* definitions that are *not*
aliases for the fe* functions; look at sysdeps/powerpc/fpu/fenv_libc.h,
for example. In such cases you'll need to rename the definitions and
uses, or otherwise rearrange things to avoid pessimization.
> [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?
Yes (bug report in Bugzilla first if fixing this, as usual; the relevant
condition is long double functions being aliases of the double versions).
Joseph S. Myers