This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Xscale big endian tool-chain (how to build it?)


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                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]