This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Cleanup MIPS preconfigure script
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Steve Ellcey <sellcey at mips dot com>
- Cc: <libc-alpha at sourceware dot org>, <matthew dot fortune at imgtec dot com>, Catherine Moore <clm at codesourcery dot com>
- Date: Fri, 5 Sep 2014 00:23:13 +0100
- Subject: Re: [PATCH] Cleanup MIPS preconfigure script
- Authentication-results: sourceware.org; auth=none
- References: <6b5ce132-2a69-4ee9-aaa5-d07792e72b50 at BAMAIL02 dot ba dot imgtec dot org> <alpine dot DEB dot 1 dot 10 dot 1409042322000 dot 27075 at tp dot orcam dot me dot uk> <1409871127 dot 2740 dot 76 dot camel at ubuntu-sellcey>
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
`mips64-linux-gnuabi32'.
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'.
Maciej