Re: RFC & patch: Rework MIPS command-line handling

[Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>]

Richard Sandiford wrote:
[snip]
> > > So the way the GAS config stuff is structured, it will assume NO_ABI
> > > by default, since that seems sensible for most embedded configs,
> > > and won't lead to spurious "incompatible ABI" link failures.
> > 
> > Spurious? With some likeliness these are real incompatibilities.
> 
> Sure, it could catch real incompatibilities, but it could generate
> false positives too.  My point is that, before now, there has been
> no default ABI assumption for "mips-elf-as", either invoked directly,
> or through the GCC driver.

Now I understand the misconception: With "ABI", I meant binary
compatibility, while you primarily meant ELF header flags.

> It hasn't been necessary to think about
> ABI flags when assembling (to pick a trivial example):
> 
> version:
>         .asciz "version (2.10)"

AFAICS this is only true for mixing o32 and NoABI code. I don't
know how relevant this is in praxis.

> I'm not saying it's necessarily bad to have a default ABI for all
> configs, but I just feel that some users might think we're being
> a bit too pedantic.

Given that the "No ABI" case is a sort of o32 under the hood,
there's not much actual difference. Of course, requiring the header
flag will break link compatibility in the transition phase, but
it prevents "spurious" link failures furtheron.

[snip]
> > > One of the changes was that the default float register size would
> > > be worked out from -mgp32, -mgp64, -msingle-float, etc.  That was
> > > mostly for multilib convenience.
> > 
> > For embedded use, I assume. For hosted systems this should be done
> > by the ABI.
> 
> Well, -mabi isn't the only GCC option that changes the ABI.

But it should, for the sake of clarity. Changing the ABI by -mips1
is a relic from the time where -mabi=o32 was disfunctional.

> At the
> moment, you need -mgp32 to select between 32-bit and 64-bit code when
> an EABI is selected.  And we have the -msingle-float variations too.
> For example:
> 
>   -mgp32 -mabi=eabi                     => -mfp32
>   -mgp64 -mabi=eabi                     => -mfp64
>   -mgp64 -mabi=eabi -msingle-float      => -mfp32
> 
> (All supported combinations, I think.)

So if we had -mabi=eabi{32,64} we could get rid of -m[fg]p* options,
at least for the EABI case. I would prefer it this way, it gives better
abstraction without losing anything.


Thiemo