Add little/big endian multilib variants to mips*-rtems*

[Ralf Corsepius]

On Sat, 2006-06-10 at 08:31 +0100, Richard Sandiford wrote:
> Ralf Corsepius <ralf.corsepius@rtems.org> writes:
> > On Fri, 2006-06-09 at 14:46 -0500, Joel Sherrill wrote:
> >> Richard Sandiford wrote:
> >> 
> >> >Joel Sherrill <joel.sherrill@oarcorp.com> writes:
> >> >  
> >> >
> >> >>Does there need to be a special error catcher for mips*el-rtems so it 
> >> >>can't be configured?
> >> >>    
> >> >>
> >> >
> >> >If it has to be mips-rtems (not mipsFOO-rtems), then I suggest
> >> >just removing the first "*" from "mips*-rtems*".
> >> >
> >> >  
> >> >
> >> We do build a mips64-rtems so that won't work. Close though.
> 
> Ah.  Won't Ralf's patch break that target too? 

No. In my understanding, mips64-rtems-gcc would be identical to
mips-rtems (except of using a different default for binutils).

That's how mips64-rtems had always been implemented, and which I had
always considered broken ...

> > Some fundamental questions, I can't answer, however would remain:
> > * Is such a mips64-*rtems* target useful at all?
> > * Has mips64-rtems* (before having added le/be multilib variants) ever
> > been useful.
> > * Can "mips64" be implemented as multilib variant of "mips"?
> 
> I think it already is. 
That's what I had presumed (In case it's not obvious, I am not a mips
specialist ;) ).

>  In configury terms, "mips64*-*-*" is
> just MIPS 3, and the current version of mips/t-rtems has -mips1,
> -mips3 and -mips32 multilibs.  It's just that mips-rtems defaults
> to -mips1 while mips64-rtems defaults to -mips3.
Great! That's what we actually want: One unified mips toolchain for all
mips targets. Greatly simplifies things for RTEMS.

I.e. I will be removing mips*-rtems* and replace it with mips-*-rtems*.

Ralf