Re: [PATCH] MIPS gas/ld test suite portability fixes

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

Richard Sandiford wrote:
[snip]
> Eric's already mentioned the old gcc behaviour of -mabi=64 implying
> -mips4, but remember that -mabi=32 also used to imply -mips1, on the
> basis that that's what the SVR4 ABI officially requires.

IIRC it was first the other way: -mabi didn't exist, -mips1/2 implied
o32, -mips3 implied n32, and -mips4 implied n64. This emulated the IRIX
toolchain's behaviour, and was found to be inadequate for other mips
platforms. Then -mabi was added, and reverse-implied -mipsX, this
opened the door for several inconsistencies.

I don't want to follow that path, I only want -mabi to ensure it has
the minimum ABI requirement satisfied.

[snip]
> Your proposal seems to be catering for the case where:
> 
>   (a) someone picks a 32-bit-only configuration that implies
>       a particular architecture; and
> 
>   (b) then tries to use it to build 64-bit code.

This currently works for

	mips-linux-gcc -mabi=n32

thanks to from-abi but fails for

	mipsisa32-linux-gcc -mabi=n32

This inconsistency is introduced just because the toolchain's ISA
default is different to MIPS I.

> Outside of running testsuites, who actually does that? It's a minor
> market, surely?

With the market argument you can "prove" that there's no need for more
than one processor architecture. :-) But I agree, it is not a widely
used feature.

> Anyone who's seriously interested in building 64-bit
> code should use a 64-bit configuration, not something like mipstx39-elf,
> mipsisa32-linux-gnu or whatever. That's especially true when you
> consider that a 32-bit-only configuration won't build any compatible
> libraries.

Which is IMHO a bug in gcc, because -mabi=n?? should be fully usable.
(If this isn't true for some mips*-elf targets, then -mabi should
probably be an invalid option for these.)


Thiemo