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: Richard Sandiford <rsandifo at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, binutils at sources dot redhat dot com, macro at ds2 dot pg dot gda dot pl
- Date: 12 Jul 2002 11:37:57 -0700
- Subject: Re: RFC & patch: Rework MIPS command-line handling
- References: <email@example.com>
> One part needs the other, really. If the GCC patch is OK, I was
> hoping to apply it before 3.2. The GAS stuff is probably too
> invasive for 2.13, though.
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
Macej said the following:
>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.
> 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.
>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.
>Well, the intent seems valid (certain sets of options make
>non-conforming files to be generated), but the check is incomplete.
>Note the ABI setting gets propagated to the ELF header of a generated
>file, so both the ABI field and the ABI invalidation code like above
>should probably remain in place.
Some sort of error checking should be there, that's part of what we get
with Richard's new patch. The old error checking was well.. error prone
and not in any way marginally complete.
I will not grease the monkey bars