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

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

 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
> >implicitly. 
> 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:, PGP key available        +

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