build errors while cross compiling llvm-gcc for ARM

I'm getting following errors while cross compiling llvm for ARM. Please help
since it is urgent and critical

My gcc version is 4.2.0, 32bit Linux and target is ARM

Configure options are:

./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--target=armv7fl-montavista-linux-gnueabi --enable-cross
--with-sysroot=/home//arm_v7_vfp_le/target/
--with-build-sysroot=/home//arm_v7_vfp_le/target/ --enable-shared
--enable-languages=c,c++ --with-as=/home//arm_v7_vfp_le/bin/arm_v7_vfp_le-as
--with-ld=/home//arm_v7_vfp_le/bin/arm_v7_vfp_le-ld
--enable-checking=release --disable-multilib
--enable-llvm=/home//Desktop/Sanjeev/LLVM/llvm-2.7 --enable-clocale=gnu
--with-cpu=cortex-a8 --with-interwork --with-arch=armv7-a --with-mode=arm
--with-tune=cortex-a8 --with-fpu=vfp3 --disable-bootstrap

I get following errors:

/home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/xgcc
-B/home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/
-B/usr/local/armv7fl-montavista-linux-gnueabi/bin/
-B/usr/local/armv7fl-montavista-linux-gnueabi/lib/ -isystem
/usr/local/armv7fl-montavista-linux-gnueabi/include -isystem
/usr/local/armv7fl-montavista-linux-gnueabi/sys-include -DHAVE_CONFIG_H -I.
-I../.././libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 -g
-O2 --sysroot=/home//arm_v7_vfp_le/target/ -MT mf-runtime.lo -MD -MP -MF
.deps/mf-runtime.Tpo -c ../.././libmudflap/mf-runtime.c -o mf-runtime.o

/dev/null 2>&1

make[4]: *** [mf-runtime.lo] Error 1
make[4]: Leaving directory
`/home//llvm-gcc-4.2-2.7.source/armv7fl-montavista-linux-gnueabi/libmudflap'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home//llvm-gcc-4.2-2.7.source/armv7fl-montavista-linux-gnueabi/libmudflap'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home//llvm-gcc-4.2-2.7.source/armv7fl-montavista-linux-gnueabi/libmudflap'
make[1]: *** [all-target-libmudflap] Error 2
make[1]: Leaving directory `/home//llvm-gcc-4.2-2.7.source'
make: *** [all] Error 2

Thanks a lot
Sanjeev

Unfortunately, the only informative part of this compilation error was
hidden by the "> /dev/null 2>&1" redirection. Could you please remove
that redirection, re-run the build, and report the actual error message?

This is the full description of errors I am getting

/home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/xgcc
-B/home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/
-B/usr/local/armv7fl-montavista-linux-gnueabi/bin/
-B/usr/local/armv7fl-montavista-linux-gnueabi/lib/ -isystem
/usr/local/armv7fl-montavista-linux-gnueabi/include -isystem
/usr/local/armv7fl-montavista-linux-gnueabi/sys-include -DHAVE_CONFIG_H -I.
-I…/…/./libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 -g
-O2 --sysroot=/home//arm_v7_vfp_le/target/ -MT mf-runtime.lo -MD -MP -MF
.deps/mf-runtime.Tpo -c …/…/./libmudflap/mf-runtime.c -o mf-runtime.o

/tmp/cczBL31y.s: Assembler messages:
/tmp/cczBL31y.s:409: rdhi, rdlo and rm must all be different
/tmp/cczBL31y.s:2742: Error: offset too big
/tmp/cczBL31y.s:2743: Error: offset too big
/tmp/cczBL31y.s:2752: Error: offset too big
/tmp/cczBL31y.s:2753: Error: offset too big
/tmp/cczBL31y.s:2762: Error: offset too big
/tmp/cczBL31y.s:2763: Error: offset too big
/tmp/cczBL31y.s:2772: Error: offset too big
/tmp/cczBL31y.s:2773: Error: offset too big
/tmp/cczBL31y.s:2778: Error: offset too big
/tmp/cczBL31y.s:2779: Error: offset too big
/tmp/cczBL31y.s:2788: Error: offset too big
/tmp/cczBL31y.s:2789: Error: offset too big
/tmp/cczBL31y.s:2801: Error: offset too big
/tmp/cczBL31y.s:2802: Error: offset too big
/tmp/cczBL31y.s:3826: Error: offset too big
/tmp/cczBL31y.s:3827: Error: offset too big
/tmp/cczBL31y.s:3840: Error: offset too big
/tmp/cczBL31y.s:3841: Error: offset too big
/tmp/cczBL31y.s:5125: Error: offset too big
/tmp/cczBL31y.s:5126: Error: offset too big
/tmp/cczBL31y.s:5130: Error: offset too big
/tmp/cczBL31y.s:5131: Error: offset too big

Hello

/tmp/cczBL31y.s:409: rdhi, rdlo and rm must all be different

This is binutils bug fixed ~2 years ago:
http://sourceware.org/ml/binutils/2007-11/msg00046.html

Make sure you're using the latest binutils for ARM (from binutils CVS)

Hello,

Thanks for the reply. We have an product whose one part has lot of algorithms doing some graphics work. Our intention was to figure out if there can be any performance gain if we use llvm instead of native ARM. This is for ARM target. Earlier, I have built this component using llvm and tested it on x86. Performance was 4x as compared to native gcc. Then I built llvm for ARM and tested this component on ARM with llvm compiler and performance of llvm+arm against native ARM was almost equal or less :frowning: However, I have run a simple sorting algorithms who run for 100K times and sort 10K elements on llvm+arm and this time it’s performance was 3x better than native ARM. Can you guys please suggest what could be there in this graphics component which is not allowing the performance to improve for ARM+llvm.

cross-compiler has been built with these flags

Using built-in specs.
Target: armv7fl-montavista-linux-gnueabi
Configured with: ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=armv7fl-montavista-linux-gnueabi --enable-cross --with-sysroot=/home/arm_v7_vfp_le/target/ --with-build-sysroot=/home/arm_v7_vfp_le/target/ --enable-shared --enable-languages=c,c++ --with-as=/home/arm_v7_vfp_le/bin/arm_v7_vfp_le-as --with-ld=/home/arm_v7_vfp_le/bin/arm_v7_vfp_le-ld --enable-checking=release --disable-multilib --enable-llvm=/home/Desktop/Sanjeev/LLVM/llvm-2.7 --enable-clocale=gnu --with-cpu=cortex-a8 --with-interwork --with-arch=armv7-a --with-mode=arm --with-tune=cortex-a8 --with-fpu=vfp3 --disable-bootstrap --disable-libmudflap --disable-libssp
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)

These are the steps how I’m building library on ARM+llvm. generated .a is linked with other targets built with native arm compiler.

g+±cross -flto -O2 -Wall -function-sections -fdata-sections ; for all .cpps
llvm-ld -link-as-library *.bc target.bc // Consolidate all .bcs into one
llc target.bc -o target.s
cross-as target.s -o target.o
ar q target.a target.o

Hi,

Any help would b appreicated. This is one of my critical assignment.

Thanks
Sanjeev

Any help would b appreicated. This is one of my critical assignment.

Well, as was already indicated - make sure that you're using the
latest binutils (2.20 is not fresh enough, btw).

No, I’m using the latest binutils.

No, I'm using the latest binutils.

What is the version of 'latest' ?

Sorry about that. As you can see, I’m using binutils (ld & as ) from arm toolchain we use to build things for our target.

arm_a_b_c_ld -v gives 2.17.50.20070611

arm_a_b_c_as -v gives 2.17.50.20070611

Do you belive that older binaries of (linker & assembler) can cause performance drop ? Unfortunately I’m not in a position to update the arm compiler for my company :slight_smile:

Sorry about that. As you can see, I'm using binutils (ld & as ) from arm
toolchain we use to build things for our target.

arm_a_b_c_ld -v gives 2.17.50.20070611

arm_a_b_c_as -v gives 2.17.50.20070611

This is definitely not the latest binutils you've stated before. As
you might see - these are at least 3 years old and are known to be
heavily buggy on ARM.

Do you belive that older binaries of (linker & assembler) can cause performance drop ?

No. They are just buggy (at least assembler).

Unfortunately I'm not in a position to update the arm compiler for my company :slight_smile:

Well, sorry, then you're not lucky then. You should expect invalid
code / spurious error messages produced in many places (and you
already saw this!)

Thanks, last doubt :slight_smile:

But I wanted to say is using these binutils I have built a llvm compiler for our ARM target.

Now our libraries which are either compiled with native ARM or with this llvm compiler gives same performance numbers. However this only llvm compiler if compared with x86 compiler gives huge performance gain.

Any idea why this might be happening ?

But I wanted to say is using these binutils I have built a llvm compiler for
our ARM target.

That's correct. Mostly because gcc is using pre-UAL ARM assembler syntax
and LLVM switched fully to UAL one. Also, UAL is needed for correct Thumb-2
support, etc. So, in short: gcc is generating some subset of ARM assembler
and thus gas is bug-free. LLVM generates somehow different subset and this
uncovered many bugs inside gas :slight_smile:

Now our libraries which are either compiled with native ARM or with this
llvm compiler gives same performance numbers. However this only llvm
compiler if compared with x86 compiler gives huge performance gain.

You mean that llvm-generated code is faster on x86, but not on ARM compared
to the vendor compiler / gcc, right?

exactly

exactly

Well, in general, there is no connection between the performance on
x86 and on ARM.
You can try to profile your code and find what causes the speedup on
x86 and figure out the slowdowns on ARM.

Hey guys,

Is there a way to force the LLVM JIT compiler to omit the frame pointer in its generated i386/amd64 code? I've got a complex situation in which the stack can potentially be moved around so I'd prefer that the base pointer doesn't get pushed there.

Félix

Take look at TargetOptions.h - http://llvm.org/doxygen/TargetOptions_8h_source.html

I thought FPO is enabled by default (I explicitly disable it), but try setting:

llvm::NoFramePointerElim = false;

Hello,

Since, I cudn’t get performance gain using llvm compiler, I’ve tried to use gold linker instead of going through these following steps.

a) ‘llvm-gcc -c -flo -O2’ to generate the .bc files.
b) ‘llvm-ld’ to combine them into a single .bc. No, not a .so nor a .a.
c) ‘llc’ to turn your combined .bc into a .s
d) ‘as’ to turn your .s into a .o

I followed instructions from web page. http://llvm.org/docs/GoldPlugin.html

I configured linker with these paramters.
…/src/configure --host=i686-pc-linux-gpu --build=i686-pc-linux-gpu --target=armv7fl-montavista-linux-gnueabi --enable-gold --enable-plugins --enable-lto --with-cpu=cortex-a8 --with-interwork --with-arch=armv7-a --with-mode=arm --with-tune=cortex-a8 --with-fpu=vfp3

Did a make then.

But the code generated with ld-new is intel binary and not a ARM binary :frowning:

I did
arm_v7_vfp-le a.c
ld-new libs a.o -o binary
file ./binary
./binary: ELF 32-bit LSB executable, intel 80386 version 1(SYSV) dynamically linked (uses shared libs), for GNU/Linux 2.6.9 not stripped

Any idea Why is it so ? Hoping for a quick reply

-Sanjeev

Hello

a) 'llvm-gcc -c -flo -O2' to generate the .bc files.

How llvm-gcc was configured & compiled?

With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

my g+±cross was configured with following parameters:

./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=armv7fl-montavista-linux-gnueabi --enable-cross --with-sysroot=/home/arm_v7_vfp_le/target/ --with-build-sysroot=/home/arm_v7_vfp_le/target/ --enable-shared --enable-languages=c,c++ --with-as=/home/arm_v7_vfp_le/bin/arm_v7_vfp_le-as --with-ld=/home/arm_v7_vfp_le/bin/arm_v7_vfp_le-ld --enable-checking=release --disable-multilib --enable-llvm=/home/Desktop/Sanjeev/LLVM/llvm-2.7 --enable-clocale=gnu --with-cpu=cortex-a8 --with-interwork --with-arch=armv7-a --with-mode=arm --with-tune=cortex-a8 --with-fpu=vfp3 --disable-bootstrap --disable-libmudflap --disable-libssp

But any file e.g. a.c compiled with g+±cross if I try to link using ld-new, I get error
ld-new libs a.o -o binary
a.o : incompatible object file

ld-new works only with those objects which are compiled using native gcc but doesn’t work for cross-compiler gcc/arm.