Running cross compiled binaries for ARM on gem5

Project Infrastructure LLVM Dev List Archives
1

Hi,

I am trying to optimize some benchmarks using LLVM and run them on gem5 simulator (build for ARM). I am using Sourcery Codebench cross-compiler for ARM on my x-86 machine.
My steps up till now have been using the following commands.

*1. clang -static -emit-llvm -march=armv7-a -mfloat-abi=soft -target arm-elf a.cpp -c -integrated-as *
*–sysroot=/home/silky/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/arm-none-linux-gnueabi/libc *
*-I/home/silky/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/arm-none-linux-gnueabi/include/c++/4.7.2/ *
-I/home/silky/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/arm-none-linux-gnueabi/include/c++/4.7.2/arm-none-linux-gnueabi/armv4t/ -o a.bc

2. llc -O3 -o a.s -march=arm a.bc

3. arm-none-linux-gnueabi-g++ -static a.s -o a_st

To run the final executable on gem5, I use

  1. /gem5$ build/ARM/gem5.debug configs/example/se.py -c /home/silky/mbench/vect/a_st

This results in a page fault -

Global frequency set at 1000000000000 ticks per second 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 **** REAL SIMULATION **** info: Entering event queue @ 0. Starting simulation… panic: Page table fault when accessing virtual address 0xfffffff4 @ cycle 2509500 [invoke:build/ARM/sim/faults.cc, line 70]

Trace :
9405000: system.cpu T0 : 0x8118 : bl : IntAlu : D=0x000000000000811c gem5.debug: build/ARM/mem/request.hh:514: Addr Request::getPC() const: Assertion `privateFlags.isSet(VALID_PC)’ failed.

Most of the search results talk about the executable not being statically compiled. Could anyone please tell me if any of the compilation commands is incorrect.
Is there any other way I can check the executable generated is not buggy?

Thanks and Regards,
Silky

2

Hi Silky,

If I got correctly, you seem to be trying to run a bare-metal image on your model, but you compile with linux-gnueabi GCC. I don’t know if that will make a difference, but I’d try to use none-eabi GCC toolchain and set the -target armv7a-none-eabi just in case.

3

Thanks Renato and Giang.

I was able to run a simple HelloWorld program on gem5 (in SE mode) by using
-target -arm-none-linux-gnueabi as the option during cross compilation.

I am trying to cross compile some Computer Vision algorithms, which use
OpenCV libraries, and I tried using the same command line options -

clang++ *-emit-llvm -static -c -Wall -g -O0 -mfpu=vfp -mfloat-abi=soft
-march=armv7-a -target arm-none-linux-gnueabi* -DCLOCK_GETTIME_TIMING
-DOPENCV_2_4
-c ../MEVBench/Benchmarks/FeatureExtraction/FeatureExtraction.cpp
-I/home/silky/VecProject/opencv/OpenCVInstall/arm/include
-I/home/silky/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/arm-none-linux-gnueabi/include/c++/4.7.2/
-I
/home/silky/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/arm-none-linux-gnueabi/include/c++/4.7.2/arm-none-linux-gnueabi/armv4t/
-o FE.bc

However, this errors out saying

/home/silky/VecProject/opencv/OpenCVInstall/arm/include/opencv2/core/mat.hpp:117:9:
error: cannot compile this atomic library call yet
        CV_XADD(refcount, 1);
        ^~~~~~~~~~~~~~~~~~~~
/home/silky/VecProject/opencv/OpenCVInstall/arm/include/opencv2/core/operations.hpp:61:38:
note: expanded from macro 'CV_XADD'
        #define CV_XADD(addr, delta)
__c11_atomic_fetch_add((_Atomic(int)*)(addr), (delta), __ATOMIC_SEQ_CST)

Could someone please suggest what I am missing here, or what the error
indicates?

Thank you all.

4

This is odd. This atomic is implemented in CGAtomic.cpp, but it's being
lowered as a library call because "UseLibcall" is true:

bool UseLibcall = (Size != Align ||
                     getContext().toBits(sizeChars) > MaxInlineWidthInBits);

I don't think it should in your case. That looks like a bug, but I'm not an
atomic library expert. Can you create a bug in bugzilla (
http://www.llvm.org/bugs/), please?

Possibly, you should send an email with this error and the bugzilla ID to
the list, just to make sure you get the attention of the right people.

cheers,
--renato

5

Hello,
This is the same issue reported here http://llvm.org/bugs/show_bug.cgi?id=15429

6

Yes, it does look like the same problem, thanks!

Silky, feel free to add your error messages to that bug to make sure it's
taken into account when fixed.

cheers,
--renato

7

Thanks Renato!
I've attached the command I used and the error message as an attachment to
the bug.