Re: RFC & patch: Rework MIPS command-line handling

[Eric Christopher <echristo at redhat dot com>]

> Having an unambiguous default ABI is desirable. If the name of the
> compiler is mips64-elf-gcc or mipsisa32-elf-gcc, then there should only
> be one ABI that defaults for each of those and it should not depend on
> how the toolchain was configured and built. Otherwise, users might need
> to always specify the ABI they want to use for every compile and that
> would be tedious and prone to errors.
> 

I agree. I feel that setting the abi at configure time isn't even under
consideration. It would be confusing and cause more problems than this
patch is fixing.

> > > 
> > > 1. Stick with the idea in the patch I sent.  Selecting a 64-bit
> > >    processor would usually select the 64-bit EABI, but adding
> > >    -mgp32 forces the 32-bit version.
> > > 
> > > 2. Reverse of (1).  You get the 32-bit version of the EABI
> > >    unless you use -mgp64.
> > > 
> > > 3. Add eabi32, eabi64, meabi32 and meabi64 to -mabi.  You get
> > >    the 32-bit version unless you use -mabi=eabi64.

> Speaking as an embedded user, any of the three options work. The first
> one has the advantage of working even if you happen to have an old
> version of the toolchain around by accident.
> 
> For the above choices, my order of preference would be: (3), (2), (1).
> However, I think there needs to be at least one release that serves as
> a transitional introduction if (3) is chosen.
> 

I want to keep #1 around. It just seems to make the best sense for me,
and we might as well keep as much backward compatibility as possible :)


> A ask a hard question...
> 
> I would have no significant problems with _MIPS_R2000 and _MIPS_R3000
> using the same value rather than being independent if that were necessary.
> 
> However, I think that if both symbols need to exist, it might be useful
> to have distinct values for them if possible.

I can agree with this...

-eric

-- 
I will not grease the monkey bars