TBB cross compilation on ARM architecture

atomic.Raf_Schietekat.20090402 is meant to be used with tbb21_20080925oss, but you only mention 3 other versions.

Please apply the following corrections in gcc_arm.h: atomic_word->tbb::internal::atomic_word, indended->intended, and try again.

I could post an already merged version by tomorrow (bigger file, though, and impossible to see what has changed without the original).

I haven't looked into setting things up for clean cross-compilation yet, but let's first worry about actually compiling the code: maybe you have to use -mcpu or -march or somesuch for your compiler to know that it has a V6 or better to work with?

(Added) Compare with SunOS.gcc.inc, where I specified -mcpu=v9 for SPARC.

Quoting - Raf Schietekat

I haven't looked into setting things up for clean cross-compilation yet, but let's first worry about actually compiling the code: maybe you have to use -mcpu or -march or somesuch for your compiler to know that it has a V6 or better to work with?

(Added) Compare with SunOS.gcc.inc, where I specified -mcpu=v9 for SPARC.

HI,I got "/tmp/ccEY8K6G.s:7389: Error: registers may not be the same -- `strex ip,ip,[r2]'" message after I specified -mcpu=mpcore for ARM11MPCORE. I'm not familiar with assembly, so what should I modify "strex" X " %[itd],%[itd],[%[ptr]]nt" /* store conditionally */ to or others? Thank you.

Could youspecify -save-temps for a bit more context?

(Correction) Not a double but a single dash at the start of the compiler option.

Quoting - Raf Schietekat

(Correction) Not a double but a single dash at the start of the compiler option.

Dear Raf Schietekat,
I got the error meesage when compile concurrent_queue.cpp. So I add -save-temps to compile it again and got three files concurrent_queue.ii ,concurrent_queue.s and concurrent_queue.d. please check with attachments. Thank you for your help.

Hmm, those files do not go together with the error message you provided earlier. But I'll have a look anyway.

(Added) Maybe I didn't really really need those files, but they did provide some inspiration and made it easier to spot and confirm the problem. I didn't see this restriction (that the registers have to be different) in the specification document, and still don't, but I'll post a new proposal shortly. Meanwhile, if you don't want to wait for that, you can probably comment out the whole __TBB_FetchOp section (lines 172-224 or so) in include/tbb/machine/gcc_arm.h; just don't trust any benchmarks you may make as final yet.

Quoting - Raf Schietekat
Hmm, those files do not go together with the error message you provided earlier. But I'll have a look anyway.

(Added) Maybe I didn't really really need those files, but they did provide some inspiration and made it easier to spot and confirm the problem. I didn't see this restriction (that the registers have to be different) in the specification document, and still don't, but I'll post a new proposal shortly. Meanwhile, if you don't want to wait for that, you can probably comment out the whole __TBB_FetchOp section (lines 172-224 or so) in include/tbb/machine/gcc_arm.h; just don't trust any benchmarks you may make as final yet.

Hi,
I have looked into http://www.keil.com/support/man/docs/armasm/armasm_cihbghef.htm . And it says "For STREX, Rd must not be the same register as Rt, Rt2, or Rn." I will follow your suggestion. Thank you very much.

"I have looked into http://www.keil.com/support/man/docs/armasm/armasm_cihbghef.htm . And it says "For STREX, Rd must not be the same register as Rt, Rt2, or Rn.""
I still don't find that where I was looking, but no matter.

Please try the attached consolidated include/tbb/machine/gcc_arm.h on top of the 2009-04-02 patch.

(Added 2009-12-07) Note that 64-bit atomics, currently relying on default delegation to __TBB_CompareAndSwap (at an unknown performance penalty relative todirect implementations), will probably require a substitution "r8"->"r8,r9" (without the quotes) at gcc_arm.h:165 and"r12"->"r12,r13" (same remark) at gcc_arm.h:170, based on the apparently more reliable specification referenced earlier, which is kinda relevant because my implementation is only based on specification and the feedback I get here from anyone actually building from the code. But we'll get there in the end! :-)

Quoting - Raf Schietekat
"I have looked into http://www.keil.com/support/man/docs/armasm/armasm_cihbghef.htm . And it says "For STREX, Rd must not be the same register as Rt, Rt2, or Rn.""
I still don't find that where I was looking, but no matter.

(Added 2009-12-07) Note that 64-bit atomics, currently relying on default delegation to __TBB_CompareAndSwap (at an unknown performance penalty relative todirect implementations), will probably require a substitution "r8"->"r8,r9" (without the quotes) at gcc_arm.h:165 and"r12"->"r12,r13" (same remark) at gcc_arm.h:170, based on the apparently more reliable specification referenced earlier, which is kinda relevant because my implementation is only based on specification and the feedback I get here from anyone actually building from the code. But we'll get there in the end! :-)

I have compile it successfully. Thank you for you kindly help.

"I have compile it successfully."
With or without the late-breaking suggestion for 64-bit support? Have you also successfully run the tests ("make all" would at some point run test_atomic)? Please also report back if anything fails later on, because tests (can) only do so much (test_atomic does not actually test atomics across threads).

Quoting - Raf Schietekat

I'm sorry for so late to report. I can successfully do "make" with and without the late-breaking suggestion for 64-bit support . However, when I type "make all",every examples are failed. I useexamples/test_all/fibonacci as sample, I directly execute "arm-unknown-linux-gnueabi-g++ -mcpu=mpcore -O2 -DNDEBUG -o fibonacci Fibonacci.cpp -ltbb -I /opt/tbb-port/basedir/include -L /opt/tbb-port/basedir/build/linux_mpcore_arm-unknown-linux-gnueabi-gcc_cc4.2.4_libc2.10.1_kernel2.6.31_release" and it shows in the attachments. Thank you.

Could it be that tbb_error.txt is empty?

Quoting - Raf Schietekat

I'm so sorry. I update the file again. Thank you.

I don't know why these link errors occur, but I see nothing platform-specific in these error messages, so a lot of people should be able to help here.

Hi,

I asked the previous in the other thread(http://software.intel.com/en-us/forums/showthread.php?t=70663) and fixed the problem. But when I execute the program which include TBB library will causes the "segmentationfault". And Mr. Alexey said that it might does not work porting to ARM11MPCORE. Is there any ways to fix the problem? Thank you for your so many helps.

Do you have a core dump file to analyse in a debugger like gdb, or can you run the program inside a debugger and deduce something from the contents of the stack at the time of the segmentation fault? I see no reason why TBB would not be portable to an architecture like ARM. It is conceivable that some example programs or even TBB itself erroneously rely on possibly stronger memory semantics for Intel Architecture, but at this time I would not be looking there yet, and I don't even remember whether that would apply to ARM.

My advice: try out a few simple examples, to see whether at least some things work, and then make them more challenging. When you've got a failing program that works on x86, use a debugger to find out what's happening.

(Added) It should be safe to comment out the following sections in include/tbb/machine/gcc_arm.h: __TBB_FetchOp, __TBB_Op(__TBB_store), __TBB_Load. The implementation will fall back to something more expensive but also more conservative. If this makes a difference, that would be a significant piece of information.

Sorry for so late to reply. I was thinking how to monitor the informations during the program executing. I used strace to see what just happened. I executed
$ strace -f -o log test
and then here is the end of the log msg.

534   set_robust_list(0x40020700, 0xc)  = -1 ENOSYS (Function not implemented)
534   futex(0xbebfde24, FUTEX_WAKE_PRIVATE, 1) = 0
534   futex(0xbebfde24, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 40351000) = -1 ENOSYS (Function not implemented)
534   rt_sigaction(SIGRTMIN, {0x403382d0, [], SA_SIGINFO|0x4000000}, NULL, 8) = 0
534   rt_sigaction(SIGRT_1, {0x40338168, [], SA_RESTART|SA_SIGINFO|0x4000000}, NULL, 8) = 0
534   rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
534   getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
534   futex(0x401219f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
534   futex(0x40121a0c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
534   futex(0x4011bb80, FUTEX_WAKE_PRIVATE, 2147483647) = 0
534   fstat64(1, {st_mode=S_IFCHR|0777, st_rdev=makedev(5, 1), ...}) = 0
534   ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
534   mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40022000
534   futex(0x403300c4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
534   brk(0)                            = 0x12000
534   brk(0x33000)                      = 0x33000
534   open("/lib/tls/v6l/fast-mult/half/libtbbmalloc.so.2", O_RDONLY) = 3
534   read(3, "177ELF1113(1334t004"..., 512) = 512
534   fstat64(3, {st_mode=S_IFREG|0755, st_size=23837, ...}) = 0
534   mmap2(NULL, 47212, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40364000
534   mprotect(0x40368000, 28672, PROT_NONE) = 0
534   mmap2(0x4036f000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0x4036f000
534   close(3)                          = 0
534   --- SIGSEGV (Segmentation fault) @ 0 (0) ---
534   +++ killed by SIGSEGV +++

The msg shows "(Function not implemented)" two times. And does it let the program crash? Or is there any other reasons? Thank you.

strace is not where I would be looking for information; see #23.

Raf,

I'm working on building libtbb2 on ARM as well, since it's a dependency of FaceBook's HipHop PHP compiler.

I also looked for your patch on the Developer site and did not locate it for download. Would you be so kind as to repost the patch, or a new patch based on current work that I can try?

I'm building natively, on Ubuntu Karmic (9.10) on the tegra2 ARM Cortex-A9 platform.

-Martin

The latest though dated version is mentioned in #144 of thread "Additions to atomic", but it's based on a version that is no longer downloadable (it was restored at some point, but is now gone again). I'm not sure whether I should upload the full patched distribution.

Serious sponsorship for an update is welcome, but it's a nontrivial effort (Intel have stopped trying). and there are many competing sources of fun and/or learning...

Hi,
Please, can I get somewhere the mentioned TBB version and the ARM patch?..

I re-enabled tbb21_20080925ossfor download again. The link to the patch (which is much more than just ARM port) is in the previous post by Raf S.

Maybe it's reasonable to locate ARM port to http://www.threadingbuildingblocks.org/file.php?fid=86 (contribution Archive)?

I still can't get the core dump info. however, without "-O2" parameter when compiling the library and tbb app , it works.