Porting TBB to ARM architecture

[stanley76726]

Recently I try to run linux applications using TBB library on ARM11 MPCore and I got some problems when cross-compiling TBB.

My cross-compilation environment is described here:
Host: Ubuntu Desktop 10.04 32-bit
Target: Embedded Linux (ARM11 MPCore)
Cross compiler: RealView Compilation Tools 4.0 (RVCT 4.0) and Codesourcery G++ 2010q1-202
TBB version: tbb21_20080925oss
TBB patch version: atomic.Raf_Schietekat.20090402

My first problem is that when I used RVCT 4.0 to compile TBB library, I got some syntax error like this:

[bash]"../../include/tbb/machine/
gcc_arm.h", line 65: Error:  #1083: Inline assembler syntax error
      __TBB_M(release,"mcr p15, 0, r0, c7, c10, 5") // Data Memory Barrier
      ^
"../../include/tbb/machine/gcc_arm.h", line 65: Error:  #1066: expected a string literal
      __TBB_M(release,"mcr p15, 0, r0, c7, c10, 5") // Data Memory Barrier

[/bash]

It's because TBB source files have many inline assembly code using the GNU assembler syntax (GAS), and it's incompatible with RVCT and vice versa. It seems that I should convert these assembly code with GAS to appropriate syntax for RVCT.
I think it is really a hard work! Can anyone give some suggestions to solve it without modifying TBB source code?

I've refered the two threads(TBB cross compilation on ARM architecture and Help with TBB in Ubuntu 9.04) and successfully cross-compiled TBB library using CodeSourcery G++, but I always got a segmentation fault when running TBB example processes as Mr. clhjoe mentioned in Help with TBB in Ubuntu 9.04. I'm not sure whether it's a bug or not. Does anyone get similar problems?

Thanks in advance!
stanley76726

[RafSchietekat]

With the revised gcc_arm.h on top of the patch, I suppose? Could you execute the program with a debugger like gdb to find out where the segmentation fault happens?

[stanley76726]

Dear Mr. Raf Schietekat,

Thanks for your response!

Do you mean the revision of atomic_word --> tbb::internal::atomic_word, indended --> intended in gcc_arm.h mentioned in the thread TBB cross compilation on ARM architecture that sammmas posted?
If yes, it's a revised gcc_arm.h.
If not, Is there any new version of patch for ARM architecture?

And I will try to find out where the segmentation fault happens and report it as soon as possilbe.

Another question is that now I try to compile the TBB library using armcc (ARM compiler in RVCT4.0) again,
If I just type "make", the error message is describe above.
After modifying the makefile, when I type "make arch=mpcore", the error message is:

[bash]lyhsin98m@lyhsin98m-desktop:~/tbb21_20080925oss_PATCHED$ make arch=mpcore
cd "./build/linux_mpcore_gcc_cc4.4.3_libc2.11.1_kernel2.6.32_release" && sh ../../build/generate_tbbvars.sh linux_mpcore_gcc_cc4.4.3_libc2.11.1_kernel2.6.32_release
cd "./build/linux_mpcore_gcc_cc4.4.3_libc2.11.1_kernel2.6.32_debug" && sh ../../build/generate_tbbvars.sh linux_mpcore_gcc_cc4.4.3_libc2.11.1_kernel2.6.32_debug
make -C "./build/linux_mpcore_gcc_cc4.4.3_libc2.11.1_kernel2.6.32_debug"  -r -f ../../build/Makefile.tbb cfg=debug tbb_root=../..
make[1]: Entering directory `/home/lyhsin98m//tbb21_20080925oss_PATCHED/build /linux_mpcore_gcc_cc4.4.3_libc2.11.1_kernel2.6.32_debug'
../../build/Makefile.tbb:39: CONFIG: cfg=debug arch=mpcore compiler=gcc os=linux runtime=cc4.4.3_libc2.11.1_kernel2.6.32
sh ../../build/generate_tbbvars.sh
armcc --arm_linux_paths --arm_linux_config_file=../../arm_linux_config.xml --translate_gcc -mcpu=mpcore -fPIC -o libtbb_debug.so.2 concurrent_hash_map.o concurrent_queue.o concurrent_vector.o itt_notify.o cache_aligned_allocator.o pipeline.o queuing_mutex.o queuing_rw_mutex.o spin_rw_mutex.o spin_mutex.o task.o tbb_misc.o mutex.o recursive_mutex.o tbb_thread.o concurrent_vector_v2.o concurrent_queue_v2.o spin_rw_mutex_v2.o   -ldl -lpthread -lrt  -shared -Wl,-soname=libtbb_debug.so.2  -Wl,--version-script,tbb.def
Warning: L6439W: Multiply defined Global Symbol tbb::internal::concurrent_queue_rep::choose(unsigned) from section .text._ZN3tbb8internal20concurrent_queue_rep6chooseEj from object concurrent_queue_v2.o rejected in favour of definition from invalid_group from object concurrent_queue.o.
Warning: L6740W: Symbol 'get_memcpy_largest_cachelinesize' versioned '' defined in 'tbb.def' but not found in any input object.
Warning: L6740W: Symbol 'get_memcpy_largest_cache_size' versioned '' defined in 'tbb.def' but not found in any input object.
Warning: L6740W: Symbol 'get_mem_ops_method' versioned '' defined in 'tbb.def' but not found in any input object.
Warning: L6740W: Symbol 'init_mem_ops_method' versioned '' defined in 'tbb.def' but not found in any input object.
Warning: L6740W: Symbol 'irc__get_msg' versioned '' defined in 'tbb.def' but not found in any input object.
Warning: L6740W: Symbol 'irc__print' versioned '' defined in 'tbb.def' but not found in any input object.
Warning: L6740W: Symbol 'override_mem_ops_method' versioned '' defined in 'tbb.def' but not found in any input object.
Warning: L6740W: Symbol 'set_memcpy_largest_cachelinesize' versioned '' defined in 'tbb.def' but not found in any input object.
Warning: L6740W: Symbol 'set_memcpy_largest_cache_size' versioned '' defined in 'tbb.def' but not found in any input object.
Error: L6218E: Undefined symbol tbb::internal::concurrent_queue_rep::choose(unsigned) (referred from concurrent_queue.o).
Finished: 0 information, 10 warning and 1 error messages.
make[1]: *** [libtbb_debug.so.2] Error 1
make[1]: Leaving directory `/home/lyhsin98m/tbb21_20080925oss_PATCHED/build/linux_mpcore_gcc_cc4.4.3_libc2.11.1_kernel2.6.32_debug'
make: *** [tbb] Error 2[/bash]

I think the first warning and the last error are really strange.

Thanks!
Stanley

[RafSchietekat]

"Is there any new version of patch for ARM architecture?"
No, that's the latest one.

[hitlin37yahoo_co_in]

hello stanley,
I'm also facing a very similar problem as yours.
I want to compile a assembly code(openmax fft implementation) onto my linux machine using code sourcery(arm-gcc).As you know grm-gcc and RVDS(armcc) are not compatible with each other,i'm facing lots of error when compiling using code sourcery.
what method do i need to follow,so that i can execute my code on arm-gcc .Do i need to change the whole code or is there any option available in RVDS,that can generate arm-gcc compatible code.

Regards
Suvir

[stanley76726]

Hello!

Sorry, I know little about openmax ftt, but it seems that openmax ftt can't be compiled by CodeSourcery G++
because of the assembly code with incompatible syntax, right?
Have you tried compiling openmax ftt using RVDS? If yes, does it work? If no, what's the difference between
the error message using CodeSourcery G++ and RVDS?

On the other hand, according to the application note 212 on ARM website, GCC inline assembly code is not compatible
with RVCT and vice versa.
If you insist to compile your assembly code by CodeSourcery G++, I think the only solution is to conditionally
use alternative copies of your assembly code with the appropriate syntax.

Best Regard,
Stanley

[stanley76726]

Dear Mr. Schietekat,

Thanks for your kindly responce and sorry for the late reply.

I think I've solved the problem.
My solution is to turn off the optimization option of CodeSourcery G++ compiler, that is, I changed the option '-O2' to '-O0' in makefile while cross-compiling the TBB source files.

I still have no idea about the exact reason causing segmentation faults, but I guess it's in relation to the inline assembly code.

Best Regards,
Stanley

[hitlin37yahoo_co_in]

Well,thaks for the reply.

I have successfully compiled OpenMax fft on rvds and it works fine and definately better than fftw3 on ARM platform as its a neon optimised.On the arm-gcc side,i'm still working on it and i think i will arrive on some conclusion soon.

[RafSchietekat]

"My solution is to turn off the optimization option of CodeSourcery G++ compiler, that is, I changed the option '-O2' to '-O0' in makefile while cross-compiling the TBB source files."
The idea is to get things to work also with optimisation on, of course... I can't guarantee that my patch is correct, though: it was based on documentation only, without access to an ARM-based environment. On the other hand, it is part of an orthogonal family of ports to different processor architectures and operating systems, with minimal ARM-specific parts, so it shouldn't be too difficult to get it right if the patch is the problem.