Re: linknamespace failures

[Joseph Myers <joseph at codesourcery 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
> follow.

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
> be
> 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
joseph@codesourcery.com