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

[Richard Sandiford <rsandifo at redhat dot com>]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> Richard Sandiford wrote:
>> >> 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.)
>> 
>> And mips-linux-gnu, mipsisa32-linux-gnu, etc. as well, presumably?
>> We don't build n32 libraries for them either, and nor should we.
>
> Why do we have -mabi then if it isn't supposed to be useful for
> userland builds?

Because we need -mabi for multi-ABI toolchains like mips64-linux-gnu,
mips-sgi-irix6.5, etc., and because it's easiest to support it
everywhere than to try to selectively enable it.

If the user knows what they're doing, and is prepared to accept the
limitations, then it can be useful.  Maciej's example of building a
64-bit kernel with mipsisa32-linux-gnu is a good example of that.
All I'm saying is that the user should expect to have to specify
the new architecture (the replacement for -mips32) in that sort
of situation.

Having every configuration accept -mabi is also useful for dejagnu
testing, just like it is in binutils.  It's also very useful for
debugging.

It would take quite a lot of extra code to get gcc itself to reject
-mabi switches for which no default libraries exist.  And what purpose
would it serve?  If the user tries to do the unsupported stuff, namely
link against libraries for a different ABI, then the linker itself will
complain.  Given the potentially useful applications of -mabi (such as
those listed above) making gcc reject the option outright just sounds
like pedantry.

Richard