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

[Joel Sherrill]

Ralf Corsepius wrote:

>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.
>>    
>>
>
>Fixing this would be trivial:
>
>--- config.gcc  (revision 114538)
>+++ config.gcc  (working copy)
>@@ -1560,7 +1560,7 @@
>        tm_defines="MIPS_ISA_DEFAULT=3 MIPS_ABI_DEFAULT=ABI_O64"
>        use_fixproto=yes
>        ;;
>-mips*-*-rtems*)
>+mips64-*-rtems | mips-*-rtems*)
>        tm_file="elfos.h ${tm_file} mips/elf.h mips/rtems.h rtems.h"
>        tmake_file="mips/t-elf t-rtems mips/t-rtems"
>        ;;
>
>
>Some fundamental questions, I can't answer, however would remain:
>* Is such a mips64-*rtems* target useful at all?
>  
>
I don't know. 

>* Has mips64-rtems* (before having added le/be multilib variants) ever
>been useful.
>  
>
Again, I don't particularly know.  I don't have a way to test such a target.

>* Can "mips64" be implemented as multilib variant of "mips"?
>  
>
I don't know.  Can gcc do this?

If the answer to this is yes, then I don't know that the answer to the 
other questions
matter.  I would rather ship one mips toolset RPM set with a big 
mulitilib.  Will
a mips-rtems binutils and gdb work with a 64-bit multilib?

If we can add 64 bit multilib options later, then it is safe to drop the 
target now.  If it is
being used, someone will complain eventually and we can add the 64 bit 
multilib variants. :)

>Ralf
>
>  
>
--joel