This is the mail archive of the
mailing list for the binutils project.
Re: RFC & patch: Rework MIPS command-line handling
- From: Eric Christopher <echristo at redhat dot com>
- To: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- Cc: Richard Sandiford <rsandifo at redhat dot com>, gcc-patches at gcc dot gnu dot org, binutils at sources dot redhat dot com
- Date: 12 Jul 2002 15:14:08 -0700
- Subject: Re: RFC & patch: Rework MIPS command-line handling
- References: <Pine.GSO.3.96.1020712210643.7646Iemail@example.com>
> Still I believe that would be more convenient. It would be simply more
> intuitive to have binutils default to the ABI that gcc uses by default,
> even though direct invoking of `as' is generally considered unsafe and the
> gcc driver may select the desired default ABI explicitly like it does e.g.
> for the endianness.
> I don't think how settings for e.g. mips64*-*-linux* would affect any
> embedded target if implemented correctly -- each interested party might
> set the default as desired.
I think you should give an example of what you mean. I don't see how
this is being affected by what's going in. I _think_ what you talking
about is having gas be absolutely dumb. Have gcc pass whatever options
it believes that it needs and let users of gas need to pass _everything_
they want on the command line - otherwise default to the configured
> With 32-bit addresses, I assume, as relocations used for o32 don't fit
> 64-bit addressing well, right? If so, that's the same as o32 from the
> binutils' point of view -- only gcc would generate different code.
You'll notice that both gcc and binutils are in this discussion ;)
> 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.
This will be a) ABI by default if it was configured with a compatible
abi. 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.
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.
I will not grease the monkey bars