arm-elf multilib issues

[Joel Sherrill]

Hi,

I ran an experiment with arm-elf.  I took every
CPU model documented in the gcc.info file and
passed it in via -mcpu=XXX.  The following
CPU models linked successfully:

arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm7m
arm7d arm7dm arm7di arm7dmi arm70 arm700 arm700i arm710
arm710c arm7100 arm720 arm7500 arm7500fe arm7tdmi arm7tdmi-s
arm710t arm720t arm740t strongarm strongarm110 strongarm1100
strongarm1110 arm8 arm810 arm9 arm920 arm920t arm922t arm940t
arm9tdmi

arm9e arm946e-s arm966e-s arm968e-s arm926ej-s arm10tdmi
arm1020t arm1026ej-s arm10e arm1020e arm1022e arm1136j-s
arm1136jf-s mpcore mpcorenovfp arm1156t2-s arm1176jz-s
arm1176jzf-s cortex-a8 cortex-a9 cortex-r4 cortex-r4f
cortex-m3 cortex-m1 xscale iwmmxt iwmmxt2 ep9312

The linker errors were similar for the failures.

 ../arm-elf/lib/libc.a(lib_a-fclose.o) does not use Maverick 
instructions, whereas a.out does
 ../arm-elf/lib/libc.a(lib_a-fclose.o) uses FPA instructions, whereas 
a.out does not
 ../arm-elf/lib/libc.a(lib_a-fclose.o) uses hardware FP, whereas a.out 
uses software FP

I notice that a lot of multilib options are
commented out in t-arm-elf. 

Do we want to enable more multilibs in arm-elf?
I am guessing based upon the messages that it will
require at least 3 more variants. 

Other architectures build more variants already so
it isn't that big a deal.

Thanks.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985