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

[Answering two messages together] writes:
> At Mon, 15 Jul 2002 17:54:45 +0000 (UTC), "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.

Hmm... I thought "o32" was a term that SGI invented.  And (going
from the n32 handbook and SGI's cc) their idea of "o32" includes
the ability to run MIPS II code.

Granted, the System V supplement says:

    Some processors might support the MIPS I ISA as a subset, providing
    additional instructions or capabilities, e.g., the R6000 processor.
    Programs that use those capabilities explicitly do not conform to
    the MIPS ABI.

but does -mabi=32 select the ABI defined there, or does it
work like SGI's -32 option?  I assumed the latter.

As for the other ABIs: I don't know whether o64 was ever formally
defined.  The Cygnus EABI spec doesn't mention any architecture
restrictions.  The MIPS EABI (at least in the draft I have)
explicitly allows you to pick an ISA.  n32 & n64 allow

> I'm wondering if the right thing to do here is have flags like
> -mstrict-abi=XXX, which also set the ISA type, or -mabi=strict-XXX...

I wonder whether it would be clearer to have a special -march
argument.  Something like -mabi=XXX -march=from-abi?  It should
make the multilib matching easier as well.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]