This is the mail archive of the binutils@sources.redhat.com 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


At Fri, 12 Jul 2002 22:16:06 +0000 (UTC), "Eric Christopher" wrote:
> >  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.
>
> 2) -mips4 -32
>   This won't work anyhow. This will produce an error.
> 
> I'll accept any feedback. Other than conceivably making gas
> non-intuitive (which is something i've also heard from Daniel), I can't
> see any other way for a reasonable set of command line options.

So, i don't know how much of a problem it would be, but at least
erroring with various ABI specs might play havoc with multilibs.  (in
particular, you'd then need all sorts of excludes...)

actually, given that there are now multiple ways to specify everything
(arch, cpu, etc.), it would seem that you need to have code, rather
than option string matching, determine which multilib you're currently
building or should be using, eh?

i.e.:

say mips-elf builds multilibs for -mips1/-mips3...

you want -march=r4000 if specified on the command line to get -mips3.
actually, you also want -march=r5000 to get -mips3, if -mips1 and
-mips3 are your only choices...

You can do some of this with MULTILIB_MATCHES, but you can't do
"fall back" at all can you.  So i guess MULTILIB_MATCHES has to learn
all of the arch and ISA names?  oi.

and if somebody wants to make that better, or wants to allow "fall
back" to best available lib, they have to hack the insides of the
multilib selection code so that it uses something other than specs...


(BTW, i think the compiler shouldn't _have_ to pass the assembler the
correct default ABI flag, i.e. so that code built with 'as' w/o flags
works right by default...  but I think it should be passing the
default or non-default ABI-related flags at all times "just to be
safe" from a badly-built as.  But that goes into the rabbit hole of
killing specs for invocation of as, doesn't it...)


OK, tally a few more points for "specs must die."  8-)



chris


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