Good news on this, though it took a day of head scratching to figure it out.
It turns out that ARM clang 3.3 and earlier implements C++ exceptions using the inefficient SJLJ exception ABI - you know, the one that calls setjmp all the time for every place an unwind might happen. Anyway, they finally got round to implementing the ARM EHABI exception ABI which is zero runtime cost and they went ahead and turned it on by default in 3.4, or at least it is being turned on by default in the Debian/Ubuntu binaries as well as the LLVM binaries. Unfortunately, it was very broken indeed. It produces ARM binaries which simply cannot catch non-trivial C++ exceptions, though otherwise work fine. This caused Boost.Thread when interrupting a thread wait to enter an infinite loop at described above, indeed if you EVER catch a type with RTTI it infinite loops. Fortunately, Chromium realised this shortly after the 3.4 release, and they've been hard at work making a EHABI implementation which actually works for 3.5. I just finished compiling 3.5 from trunk and I can confirm that all Boost.AFIO unit test pass swimmingly with it for armhf. You can read more about the 3.5 ARM exception handling improvements at http://llvm.org/docs/ReleaseNotes.html#changes-to-the-arm-backend. Can I recommend you upcall this to Debian as well and recommend that they mark clang 3.4 as broken on ARM? Either that or have them patched to disable EHABI exception handling? Niall -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to llvm-toolchain-3.4 in Ubuntu. https://bugs.launchpad.net/bugs/1349789 Title: clang armhf in trusty simply doesn't work Status in “llvm-toolchain-3.4” package in Ubuntu: Confirmed Bug description: I'm running Ubuntu 14.04 on armhf. clang is from the standard repo: root@tegra-ubuntu:~# apt-cache show clang Package: clang Priority: optional Section: universe/devel Installed-Size: 27 Maintainer: Ubuntu Developers <ubuntu-devel-disc...@lists.ubuntu.com> Original-Maintainer: LLVM Packaging Team <pkg-llvm-t...@lists.alioth.debian.org> Architecture: armhf Source: llvm-defaults (0.21ubuntu1) Version: 1:3.4-0ubuntu1 Replaces: clang (<< 3.2-1~exp2) Depends: clang-3.4 (>= 3.4~rc3-1~) Filename: pool/universe/l/llvm-defaults/clang_3.4-0ubuntu1_armhf.deb Size: 2478 MD5sum: eadb3f7c344e364480bdf7fdd0f698ab SHA1: ec4d0bfcad42bf536ee8d9257f8930dd32e1a261 SHA256: f6d9a8fbfc06d93cd4c1a2437114454cc1eec805a635efc490a7e1e6eec2b3de Description-en: C, C++ and Objective-C compiler (LLVM based) Clang project is a C, C++, Objective C and Objective C++ front-end for the LLVM compiler. Its goal is to offer a replacement to the GNU Compiler Collection (GCC). . Clang implements all of the ISO C++ 1998 and 2001 standards and also provides a partial support of C++1y. . This is a dependency package providing the default clang compiler. Description-md5: ea1f164ac255f39c6ec78685f71ef19b Bugs: https://bugs.launchpad.net/ubuntu/+filebug Origin: Ubuntu Anyway, it does not produce working output. Here are some examples: https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Build%20POSIX_ARM_clang%203.4/9/consoleFull This log shows how clang has the wrong default target CPU, so it outputs unsupported ARM instructions (see the end after the warnings spew). If I force the target cpu to a cortex-a15 it now at least compiles and links and starts to run unit tests: https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Test%20POSIX_ARM_clang%203.4/7/consoleFull ... but hangs in the first unit test, and is timed out. Before you think it the unit tests, here is the exact same thing for GCC 4.8: https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Test%20POSIX_ARM_GCC%204.8/7/console The unit tests all run and pass as expected. Everything also works fine on x86 and x64 with clang 3.4 on Ubuntu 14.04, this appears to be an armhf misconfiguration. Niall To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1349789/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
