This is the mail archive of the
mailing list for the binutils project.
Re: RFC & patch: Rework MIPS command-line handling
- From: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>
- 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, macro at ds2 dot pg dot gda dot pl
- Date: Sun, 14 Jul 2002 19:43:16 +0200
- Subject: Re: RFC & patch: Rework MIPS command-line handling
- References: <email@example.com> <firstname.lastname@example.org>
Eric Christopher wrote:
> >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.
I'd prefer this, too. My local patch for mips64*-*-linux* uses n32
as default because n64 is only useful for OS kernels and WRT userland
for large memory machines.
> 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.
AFAICS this is done in the target specific code, so it is already
> 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.
And then they invented the (undocumented) -mabi switch, I assume
because automatic switching didn't work particularily 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.
It was simply a hack to make things a little bit better without breaking