This is the mail archive of the
mailing list for the binutils project.
Re: RFC & patch: Rework MIPS command-line handling
- From: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- To: Eric Christopher <echristo at redhat dot com>
- Cc: Richard Sandiford <rsandifo at redhat dot com>, gcc-patches at gcc dot gnu dot org, binutils at sources dot redhat dot com
- Date: Fri, 12 Jul 2002 21:44:15 +0200 (MET DST)
- Subject: Re: RFC & patch: Rework MIPS command-line handling
- Organization: Technical University of Gdansk
- Reply-to: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
On 12 Jul 2002, Eric Christopher wrote:
> I obviously approve of the patch since we've had a lot of long
> conversations about it :)
> I'd like to see the gas bits in 2.13 so that it can coincide with the
> next gcc release as well since we're trying to keep things as close as
For me it's obviously OK -- if any problems arise we still have some time
before 2.13 to fix them.
> >I'd prefer to select the default ABI at the configure time, from the
> >target triplet ideally. E.g. I use a local patch that select the 64
> >ABI as the default for binutils if configuring for mips64*-*-linux*.
> >The same is set in the specs file for gcc for this target.
> This is only particularly convenient for the hosted toolchains, and I
> don't think I want to get into the habit of splitting things between
> OSes and embedded toolchains.
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.
> > Hmm, what is "o64"?
> A 64-bit extension of o32 for use with 64-bit processors. It has been
> around for a long time now. Originally designed by Jim Wilson afaik.
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.
> >As I stated, the best approach I can see is not to switch the ABI
> This is probably only convenient with hosted toolchains. Also, many
> people are accustomed to the toolchain deciding ABI for them. Also, the
> historical precedent (not always something to look at, but...) of the
> SGI compiler switches ABI based on -mipsX switch as well.
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.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: email@example.com, PGP key available +