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: Mon, 15 Jul 2002 08:22:06 +0200 (MET DST)
- Subject: Re: RFC & patch: Rework MIPS command-line handling
- Organization: Technical University of Gdansk
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
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: email@example.com, PGP key available +