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: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>
- Cc: Richard Sandiford <rsandifo at redhat dot com>, gcc-patches at gcc dot gnu dot org, binutils at sources dot redhat dot com
- Date: Tue, 16 Jul 2002 13:04:54 +0200 (MET DST)
- Subject: Re: RFC & patch: Rework MIPS command-line handling
- Organization: Technical University of Gdansk
On Mon, 15 Jul 2002, Thiemo Seufer wrote:
> There seems to be some misconception about the term 'ABI', maybe
> because the current -mabi=FOO option basically means "select calling
> conventions and register sizes". But an ABI is a much more powerful
> concept than pushing a few compiler options. It defines a platform
> over a variety of hardware which allows to run the same binary code.
As I already stated, the compromise might be to add an option to select
the code conventions regardless of the ABI and then make all the "-mabi="
options strict, i.e. select both a convention and an ISA and be
incompatible with both "-march=" and the convention selection option (bail
out if specified).
> > I agree that might be true for embedded configs. But like Maciej
> > said, it could be useful to have a default ABI for hosted toolchains
> > like mips64-linux-gnu. It seems reasonable that anyone using such
> > an assembler would be at least try to write ABI-conformant code.
> I don't know about embedded configs. Just have a look at the linux
> kernel. I claim it has nearly no assembly code which could be written
> in an ABI-conformant way, with few performance improvements in assembly
> as an exception.
The kernel is special -- it's not a real target for a toolchain (it
doesn't even use PIC for MIPS). Think e.g. glibc which uses assembly
directly here and there.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: firstname.lastname@example.org, PGP key available +