Multilib mips build question

Multilib mips build question

[Steve Ellcey]

I have a question about building a mips glibc multiple times for a multilib
target.  I want to build glibc for mips with 3 targets (more actually, but 3
will serve to explain my question), mips32r2 with the old 32 bit ABI, mips64r2
with the new 32 bit ABI, and mips64r2 with the 64 bit ABI.

My first thought was to build each in a different location and that works
but it since the libraries for each of these targes wind up in lib, lib32,
and lib64, it seems clear that the intent is to build them into a single
sysroot location with a single set of header files, and have lib, lib32,
and lib64 under that one sysroot location.  That also avoids having duplicate
header files but that leads to my question.

Before rebuilding to a single sysroot I looked at the usr/include directories
for each of these builds and while the include files for the two mips64r2
builds match, the usr/include/huge_vall.h and usr/include/ieee754.h files in
the mips32r2 include directory are different then the mips64r2 ones.  I think
this is due to the Implies files.

The ports/sysdeps/mips directory and the ports/sysdeps/mips/mips64 directory
have Implies that contain:

        # MIPS uses IEEE 754 floating point.
        ieee754/flt-32
        ieee754/dbl-64

But in ports/sysdeps/mips/mips32 directory there is:

        mips
        wordsize-32

I am not sure why this difference exists or if it should.  Can anyone
help me understand why the mips setup is this way?

Steve Ellcey
sellcey@mips.com

Re: Multilib mips build question

[Joseph S. Myers]

On Tue, 25 Sep 2012, Steve Ellcey  wrote:

> Before rebuilding to a single sysroot I looked at the usr/include directories
> for each of these builds and while the include files for the two mips64r2
> builds match, the usr/include/huge_vall.h and usr/include/ieee754.h files in
> the mips32r2 include directory are different then the mips64r2 ones.  I think
> this is due to the Implies files.

I advise working out what is correct for MIPS (possibly headers with ABI 
conditionals) and then creating appropriate MIPS-specific versions of 
these headers

> The ports/sysdeps/mips directory and the ports/sysdeps/mips/mips64 directory
> have Implies that contain:
> 
>         # MIPS uses IEEE 754 floating point.
>         ieee754/flt-32
>         ieee754/dbl-64
> 
> But in ports/sysdeps/mips/mips32 directory there is:
> 
>         mips
>         wordsize-32
> 
> I am not sure why this difference exists or if it should.  Can anyone
> help me understand why the mips setup is this way?

The general answer for Implies entries is that they set up a directory 
ordering that empirically is correct, and changing them is risky because 
almost any change can perturb the ordering and cause unintended changes to 
what files are used.  See discussion on libc-alpha over the past year 
about the problems with Implies files.

Accordingly, to get headers with the right conditionals in them used 
everywhere, it might well make sense to create a new mips/float (for 
example) sysdeps directory with just the two headers in question in it (in 
MIPS-specific versions allowing for the different ABIs), as if the 
directory just has the two headers then it's reasonably safe to add to the 
top of the relevant Implies files (though you need to check that does 
really work to get the desired header installed for all ABIs).

More generally, it may often be the case that headers for 64-bit ABIs work 
for 32-bit but not vice versa.  Only in 2.16 was this fixed for x86 so 
that a single unified set of headers is installed for all ABIs; it's not 
particularly surprising that MIPS still needs some work to get to that 
point of having identical headers installed whatever ABI.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Multilib mips build question

[Steve Ellcey]

On Tue, 2012-09-25 at 22:15 +0000, Joseph S. Myers wrote:
> On Tue, 25 Sep 2012, Steve Ellcey  wrote:
> 
> > Before rebuilding to a single sysroot I looked at the usr/include directories
> > for each of these builds and while the include files for the two mips64r2
> > builds match, the usr/include/huge_vall.h and usr/include/ieee754.h files in
> > the mips32r2 include directory are different then the mips64r2 ones.  I think
> > this is due to the Implies files.
> 
> I advise working out what is correct for MIPS (possibly headers with ABI 
> conditionals) and then creating appropriate MIPS-specific versions of 
> these headers

While investigating huge_vall.h I found that neither of the copies of
this header file are coming from a mips specific directory.  One is
coming from bits/huge_vall.h and one from
sysdeps/ieee754/ldbl-128/bits/huge_vall.h.  The one under sysdeps has
support for the 2.96 and older GCC compilers.  If we removed this then
the two files would be identical.  Could we do this?  Or if the two
would then be identical could we get rid of one of them entirely?

That would fix one of my two multilib header files issues on MIPS.

Steve Ellcey
sellcey@mips.com

Re: Multilib mips build question

[Joseph S. Myers]

On Wed, 26 Sep 2012, Steve Ellcey wrote:

> On Tue, 2012-09-25 at 22:15 +0000, Joseph S. Myers wrote:
> > On Tue, 25 Sep 2012, Steve Ellcey  wrote:
> > 
> > > Before rebuilding to a single sysroot I looked at the usr/include directories
> > > for each of these builds and while the include files for the two mips64r2
> > > builds match, the usr/include/huge_vall.h and usr/include/ieee754.h files in
> > > the mips32r2 include directory are different then the mips64r2 ones.  I think
> > > this is due to the Implies files.
> > 
> > I advise working out what is correct for MIPS (possibly headers with ABI 
> > conditionals) and then creating appropriate MIPS-specific versions of 
> > these headers
> 
> While investigating huge_vall.h I found that neither of the copies of
> this header file are coming from a mips specific directory.  One is
> coming from bits/huge_vall.h and one from
> sysdeps/ieee754/ldbl-128/bits/huge_vall.h.  The one under sysdeps has
> support for the 2.96 and older GCC compilers.  If we removed this then
> the two files would be identical.  Could we do this?  Or if the two
> would then be identical could we get rid of one of them entirely?

For any IEEE platform, the HUGE_VAL* macros are infinities and a cast of 
HUGE_VAL to long double is a correct definition of HUGE_VALL as long as 
the HUGE_VAL definition itself was correct[*].  On that basis alone, I 
don't think the ldbl-128 version of the header is needed.  But considering 
the issue further:

For MIPS, GCC gained mips64-linux support in version 3.4, so the support 
for older compilers is irrelevant.

All the other architectures using ldbl-128 are using ldbl-64-128 because 
support for 128-bit long double was only added in glibc 2.4.  The GCC 
versions potentially affected by the difference in headers are those 
before 3.3.  In 3.2, Alpha only had 128-bit long double support for OSF, 
S390 didn't have it at all and SPARC has its own bits/huge_vall.h header 
so should be unaffected by this issue anyway.  The lack of Linux support 
for 128-bit long double for Alpha and S390 in older GCC means that a 
header doing anything special for it wouldn't be right with pre-3.3 
compilers on those architectures anyway.

So I believe you can propose removal of the ldbl-128 version of 
huge_vall.h on libc-alpha, for the above reasons.  In fact, for the same 
reason about the generic version being correct for any platform with IEEE 
floating point, I believe it would be OK to remove the x86, sparc, ia64 
and m68k versions of this header as well, leaving just the generic one.

[*] Ignoring any questions about the definitions in terms of a constant 
0x1.0p2047 that overflows double but not long double - if excess precision 
means that the constant is actually evaluated as long double then the cast 
might not give correct results.  But GCC didn't implement that aspect of 
excess precision at all until 4.5, so it's irrelevant to the code for GCC 
versions 2.96 to 3.2.

-- 
Joseph S. Myers
joseph@codesourcery.com