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

 I mean, if I configure for e.g. mips64*-*-linux*, I want e.g. 
"-march=4000 -mabi=64" be the default and with mips*-*-linux*, I want e.g.
"-march=3000 -mabi=32".  Someone else might want to configure for
mips64*-something-else and get "-march=8000 -mabi=n32" or configure for
mips*-something-else and get "-march=4000 -mabi=32".  The defaults
shouldn't affect one another. 

> 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
> values?

 I'm simply unsure if guessing any non-defaults is good to have.  E.g. 
with the defaults as proposed above I don't think the ABI should be
changed if "-march=R5000" was specified.  For "-march=R3000" it would be
sane to bail out with an error message for the 64-bit ABIs instead of
silently switching to "-mabi=32" which could lead to a bad object file to
be generated (which you'd not notice until after a long period, since the
file is put in an ar archive an not pulled most of the time, for example). 

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

 Let's assume I have a 32-bit MIPS system running on the R4000 CPU and the
toolchain is configured to default to "-mabi=32".  And I want to generate
optimal binaries.  So I add "-march=4000 -mtune=4000" to flags for the
toolchain.  Should I have to add "-mabi=32" explicitly?

> 2) -mips4 -32
>   This won't work anyhow. This will produce an error.

 Why?  This is a valid configuration.  I may have a 32-bit R8000 system
which is, again, configured to default to "-mabi=32".  And I want to
generate code optimized for this exact CPU (including the "movn" and
"movz" instructions), not caring about backward compatibility.  Is it


+  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]