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.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
