© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
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://
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