This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Cleanup MIPS preconfigure script

On Thu, 4 Sep 2014, Steve Ellcey wrote:

> >  Hmm, that's quite a change in the interpretation of host triplets, but 
> > I'm leaning towards finding it acceptable, I think we have sufficient 
> > means in GCC nowadays to control the default ABI so that we don't have to 
> > rely on suffixes in the triplets.  I wonder if a sanity check wouldn't be 
> > good to have though, such as rejecting mips64* with the compiler set to 
> > the 32-bit ABI to trap accidental silly use.
> Someone might want to use a 32 bit ABI on mips64 though, how about a
> warning instead of an error for that case?

 Hmm, I never thought of such use and I keep considering it weird, but 
having looked through the current script again we already permit e.g. 
`mips64-linux-gnuabi32' to select o32, so I take my concern back, no need 
for any checks here.

> >  Your change has a flaw though, you can't rely on _MIPS_ISA being set 
> > exactly to _MIPS_ISA_MIPS64 on determining if you want a 64-bit or a 
> > 32-bit configuration, there are other 64-bit ISAs, starting from 
> > _MIPS_ISA_MIPS3, e.g. I have an n64 MIPS III compiler.  I think you can 
> > just skip this check altogether, GCC will have set the ABI and the ISA 
> > consistently already and you can merge the two legs of this conditional 
> > into one.  You may just sanity-check that a 64-bit ABI is not used 
> > together with the MIPS16 option as we have no 64-bit MIPS16 PIC support.
> I like the idea of not using _MIPS_ISA.  The other difference between
> the 32 and 64 branches is setting 'base_machine' and it doesn't look to
> me that we use base_machine anywhere.  The only use of it anywhere in
> glibc that I see is in the x86_64 preconfigure script.  I agree that
> using mips16 with n32 or n64 should be an error.  I will update the
> patch.

 Good.  Frankly (with the observation I made above) I think there should 
be no difference between configuring for `mips-linux-gnu' and 

 I think the current arrangement has its historical reasons, there was a 
time when the Linux kernel had separate `mips' and `mips64' ports -- 
arch/mips and arch/mips64 as well as include/asm-mips and 
include/asm-mips64 for code and headers respectively (now asm headers live 
under arch/ too).  For glibc it was the latter that mattered as kernel 
headers are needed in our build process and had to be fetched from the 
correct place, with the usual default being /usr/src/linux/include/linux 
and /usr/src/linux/include/asm-<cpu>.  Hence the distinction and maybe the 
presence of `kern64'.  The `mips64' port supported all the three ABIs so 
any of them could have been selected to be built for.

 Of course all it does not matter anymore, the MIPS port of Linux was the 
first to merge its 32-bit and its 64-bit variant and other ports followed, 
e.g. `sparc' and `sparc64'.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]