This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> abi.

Parse error. Which ABI would this mean for e.g.

	mips-linux-gcc -march=4000

> 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
	need these.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]