On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Tue, 2006-01-03 at 15:52, Karel Gardas wrote:
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Tue, 2006-01-03 at 15:38, Karel Gardas wrote:
OK, if I understand you well, then I should not use -msoft-float for both:
compiling of eCos lib and then for compiling my eCos-based app. The
problem is that this is not right way how to workaround this issue. I've
checked that I'm not using -msoft-float neither for building eCos lib nor
for building eCos-based app. I've saved typescript of `make' so I'm sure
build does not use -msoft-float anywhere and the issue is still the same.
FYI: Options used for eCos lib build are:
-finline-limit=7000 -Wa,-mfpu=softfpa -mbig-endian -mcpu=xscale -Wall
-Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2
-ffunction-sections -fdata-sections -fno-exceptions -mapcs-frame
Try taking -Wa,-mfpu=softfpa out as well. That will probably have the
same adverse effect on the object files generated.
OK, I've removed this and got this one now:
silence:~/usr/local/xscale-ecos-default/ixdp425_install/examples$
arm-elf-gcc -mbig-endian -O2 -g hello.c -o hello.xg -I../include -L../lib
-nostdlib -Ttarget.ld
/home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld:
ERROR: /tmp/ccKN8dgp.o uses FPA instructions, whereas hello.xg does not
/home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld:
failed to merge target specific data of file /tmp/ccKN8dgp.o
/home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld:
ERROR:
/home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/be/libgcc.a(_udivsi3.o)
uses FPA instructions, whereas hello.xg does not
....
Anyway, I've now compared fpu and common libgcc and found that really fpu
(which should be hard-float) is different from the common lib in be
subdirectory (I'm talking about gcc/be/libgcc.a and gcc/be/fpu/libgcc.a),
so my assumption about building hard-float libgcc by default is not true
neither.
Do you have any idea how to proceed with this?
Ug, this would appear to be a bundle of different options plus a
build-process that ends up with everything conflicting[1] with itself...
;-(
First of all, you can't in general just copy in the old version of
t-arm-elf into a later version of GCC and expect it to work correctly.
Compare the gcc-4.0.x version against the sample one from the website
and then uncomment the relevant bits to suit your needs (this is for the
multilibs stuff). You probably won't need everything, but if you
closely mimic what's been done before you should have fewer problems.
The options are generally grouped, so if you uncomment one option, make
sure you uncomment the entire group.
Next, I suggest you add --with-cpu=xscale when configuring GCC. You can
then drop the -mcpu=xscale when compiling (this should also give you
better libraries for your system). However, beware that you libraries
will now only run on ARMv5 or later processors.
I have tried this with binutils 2.16.1 and gcc 4.0.1, but w/o success. The
failure happen during compilation of gcc and it looks like:
/tmp/arm-elf-build/obj-gcc/gcc/xgcc -B/tmp/arm-elf-build/obj-gcc/gcc/
-nostdinc -B/tmp/arm-elf-build/obj-gcc/arm-elf/newlib/ -isystem
/tmp/arm-elf-build/obj-gcc/arm-elf/newlib/targ-include -isystem
/tmp/arm-elf-build/gcc-4.0.1/newlib/libc/include
-B/home/karel/usr/local/arm-elf1/arm-elf/bin/
-B/home/karel/usr/local/arm-elf1/arm-elf/lib/ -isystem
/home/karel/usr/local/arm-elf1/arm-elf/include -isystem
/home/karel/usr/local/arm-elf1/arm-elf/sys-include -O2 -DIN_GCC
-DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include
-Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc -I. -I. -I../../gcc-4.0.1/gcc -I../../gcc-4.0.1/gcc/.
-I../../gcc-4.0.1/gcc/../include -I../../gcc-4.0.1/gcc/../libcpp/include
-mhard-float -DL_addsubdf3 -xassembler-with-cpp -c
../../gcc-4.0.1/gcc/config/arm/lib1funcs.asm -o libgcc/fpu/_addsubdf3.o
../../gcc-4.0.1/gcc/config/arm/ieee754-df.S: Assembler messages:
../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:454: Error: selected processor does
not support `mvfeqd f0,#0.0'
../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:476: Error: selected processor does
not support `mvfeqd f0,#0.0'
../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:530: Error: selected processor does
not support `ldfd f0,[sp],#8'
make[2]: *** [libgcc/fpu/_addsubdf3.o] Error 1
make[2]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc'
make: *** [all-gcc] Error 2
First of all, I've thought this is because of my original binutils
binaries configured with out --with-cpu=xscale, but even if I add this
configure switch and rebuild them, the issue is still the same. Perhaps,
my bintutils config is still wrong? But I'm short of ideas what to do
now...
Thanks!
Karel
PS: in gcc/config/arm/t-arm-elf I only uncommented those options to get BE
build:
MULTILIB_OPTIONS += mlittle-endian/mbig-endian
MULTILIB_DIRNAMES += le be
MULTILIB_MATCHES += mbig-endian=mbe mlittle-endian=mle
MULTILIB_OPTIONS += mhard-float/msoft-float
MULTILIB_DIRNAMES += fpu soft
MULTILIB_EXCEPTIONS += *mthumb/*mhard-float*
MULTILIB_OPTIONS += mno-thumb-interwork/mthumb-interwork
MULTILIB_DIRNAMES += normal interwork
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
