[LLVMdev] Running cross compiled binaries for ARM on gem5

[Silky Arora]

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

4. /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

[Renato Golin]

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.

On 10 March 2013 00:26, Silky Arora <sil...@umich.edu> wrote:

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?

The options -target may not be correct. LLVM/Clang will silently ignore unknown triples and will choose the default for whatever else it thinks is appropriate. I'd use the one I mentioned above.

To make sure it's not a bug in the model, I'd run on other models (like QEMU) or run in real hardware.

cheers,

--renato

[SArora]

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.




--
View this message in context: http://llvm.1065342.n5.nabble.com/Running-cross-compiled-binaries-for-ARM-on-gem5-tp55767p56023.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Renato Golin]

On 17 March 2013 22:40, SArora <sil...@umich.edu> wrote:

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)

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

[Abdoulaye Walsimou Gaye]

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

[Renato Golin]

On 18 March 2013 09:43, Abdoulaye Walsimou Gaye <a...@embtoolkit.org> wrote:

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

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

[SArora]

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




--
View this message in context: http://llvm.1065342.n5.nabble.com/Running-cross-compiled-binaries-for-ARM-on-gem5-tp55767p56039.html