This is the mail archive of the
mailing list for the binutils project.
Re: RFC & patch: Rework MIPS command-line handling
Eric Christopher wrote:
> > How can you guess an ABI from anything else? If I pass the "-march=4000"
> > option, then which ABI do I mean? If I pass "-mips4" for conditional
> > moves, then why should I add "-32" to keep the ABI unchanged? OK, if done
> > carefully, the guess may probably be made harmless to uninterested parties
> > -- I'll have to study the proposed changes thorougly to decide if the new
> > code does it in an acceptable way.
> 1) -march=4000
> This will be a) ABI by default if it was configured with a compatible
Parse error. Which ABI would this mean for e.g.
> The "next compatible" abi if not. An idea was to warn if we had to
> change the ABI. I don't know what people think about this - I do know
> that many people get testy if new warnings are produced.
> 2) -mips4 -32
> This won't work anyhow. This will produce an error.
Allowing MIPS IV opcodes in otherwise o32 conformant code is useful.
> I'll accept any feedback. Other than conceivably making gas
> non-intuitive (which is something i've also heard from Daniel), I can't
> see any other way for a reasonable set of command line options.
-mabi=FOO for strictly ABI-conforming code.
-march=BAR to allow processor-specific opcodes, sacrifice ABI conformance.
-mtune=BAZ to schedule for a non-default CPU.
-mgp32/-mfp32 to restrict register sizes. This may issue a warning if an
user specified ABI is incompatible. Only embedded code should