This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: RFC & patch: Rework MIPS command-line handling
Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> I agree, -mipsN should be an alias for the equivalent -march=FOO.
> Please note that the -mipsN options should IMHO be obsoleted:
>
> - They are asymmetric because all of them can be replaced by
> -march=FOO, but there are -march=FOO without -mipsN equivalents
I'd guess the ISA levels are more well known than the processors we're
associating them with, so there's probably no harm in keeping them as
aliases, but...
> - They are confusing because it's often guessed they do ISA
> selection, but they actually do CPU selection, which is quite
> a difference for GAS. (For current GCC they attempt to do ABI
> selection, too)
...agreed here.
> - As CPU aliases they can allow opcodes which aren't available
> on other ISA-conforming CPUs.
Not sure what you mean. Do you have any examples?
> I don't see a good reason to mix ISA and ABI selection. AFAICS it's
> enough to
>
> - choose the lowest ISA required for a selected ABI
>
> - use the 'highest' ABI for any selected ISA
I'm not sure what you mean by "mix" here. Anyway, I don't think
it's a good idea to select the lowest ISA for an ABI. If you have
a configuration that uses a particular CPU by default (let's say a
MIPS II one), specifying an ABI shouldn't "downgrade" to MIPS I.
If someone's using a MIPS II or higher toolchain to generate code
that must run on a MIPS I machine, it doesn't seem unreasonable
to ask them to say so explicitly.
> GCC and GAS have different requirements: For GCC it's sensible to guess
> ISA from ABI and vice versa because it usually handles ABI-conforming
> code. For GAS, the ABI selection is not that useful because assembly
> normally isn't ABI-conformant (which would be limited to opcodes covered
> in the respective ISA).
I agree that might be true for embedded configs. But like Maciej
said, it could be useful to have a default ABI for hosted toolchains
like mips64-linux-gnu. It seems reasonable that anyone using such
an assembler would be at least try to write ABI-conformant code.
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.
Not setting EF_MIPS_ABI is also the historical behaviour.
There's then the option of overriding the NO_ABI default for
particular configurations.
> > For example, if "mips64-elf-gcc -mips1" chooses o32 code
> > (as it does now) then "mips64-elf-gcc -march=r3000" should do the same.
>
> This may break the 'No ABI' case which means default ABI plus e.g.
> -mlong64 as it is used in the embedded world. OTOH, basing this usage
> on o32/o64 in future is probably a good idea.
I'm not sure how it could break things like that. -mlong64 only
controls type sizes.
> > (a) It seems counter-intuitive for -mabi to override the default
> > architecture even when that default was compatible. For
> > example, "mipsisa32-elf-gcc -mabi=o32" would generate
> > MIPS I code rather than MIPS 32 code.
>
> Strictly speaking, MIPS 32 code isn't conforming to o32 ABI.
> The same should be true for MIPS IV opcodes in n32 code.
Hmm... not sure why, but if it's related to...
> This would mean the User can use
>
> gcc -mabi=32
>
> and then he gets code which might _not_ run on o32 conformant
> Systems. This defeats the idea of having an ABI.
It sounds like you're saying that, because the original o32 systems were
MIPS I only, -mabi=32 should mean "generate MIPS I code" unless the user
says otherwise. That's the current behaviour, but like I said above,
it seems strange to pick MIPS I regardless of the default processor.
> > (OPTION_FP64): New.
> > (md_longopts): Add -mfp64, remove -mcpu.
>
> There's little reason to have -m[gf]p64, see
> http://sources.redhat.com/ml/binutils/2001-07/msg00417.html
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. GAS can generate -mgp32 -mfp64
"no ABI" code, so we'd need the -mfp64 option then. Why anyone
would use it, well, who knows? But someone once went to a lot of
effort to make it work in GCC too (although it doesn't any more).
Anyway, it sounds like there's more support than I expected for
the idea of leaving the ABI unchanged unless the command line
says otherwise. Which means the special treatment of -mgp32
might not be necessary after all...
Richard