C++ exceptions in freebsd-arm doesn't seem to work
Olavi Kumpulainen
olavi.m.kumpulainen at gmail.com
Fri Aug 29 16:34:06 UTC 2014
On 25 Aug 2014, at 20:48 , Ian Lepore <ian at FreeBSD.org> wrote:
> On Thu, 2014-08-21 at 18:54 +0200, Olavi Kumpulainen wrote:
>> On 20 Aug 2014, at 21:19 , Ian Lepore <ian at FreeBSD.org> wrote:
>>
>>> On Wed, 2014-08-20 at 19:19 +0200, Olavi Kumpulainen wrote:
>>>> On 19 Aug 2014, at 20:21 , Ian Lepore <ian at FreeBSD.org> wrote:
>>>>
>>>>> On Tue, 2014-08-19 at 19:40 +0200, Olavi Kumpulainen wrote:
>>>>>> On 25 Jul 2014, at 23:44 , Andreas Tobler <andreast-list at fgznet.ch> wrote:
>>>>>>
>>>>>>> On 22.07.14 23:11, Ian Lepore wrote:
>>>>>>>> On Sat, 2014-07-19 at 16:35 -0600, Ian Lepore wrote:
>>>>>>>>> On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote:
>>>>>>>>>> [c++ exceptions don't work and related discussion]
>>>>>>>>>
>>>>>>>>> I checked in a partial fix for c++ exception handling in r268893. It
>>>>>>>>> fixes the specific problem you detailed above, which was essentially
>>>>>>>>> that the __gnu_Unwind_Find_exidx() function was not available in any
>>>>>>>>> shared library, making the unwinder fall back to using the __exidx_start
>>>>>>>>> and end symbols, which are only valid in a statically-linked app.
>>>>>>>>>
>>>>>>>>> With the new function in place, exceptions are closer to working with
>>>>>>>>> gcc 4.2.1, but still don't work with clang. With gcc, some things work
>>>>>>>>> and some things don't. For example if you throw an exception and in the
>>>>>>>>> same function have a catch with the right specific type it segfaults,
>>>>>>>>> but a catch(...) will catch it without problems. But you can catch an
>>>>>>>>> exception by type if the catch is in a function higher up the call chain
>>>>>>>>> from the place it was thrown.
>>>>>>>>>
>>>>>>>>> We're continuing to debug this at $work, and welcome any input if anyone
>>>>>>>>> else makes progress with it. Right now we still don't know whether the
>>>>>>>>> segfaults are because of bad unwinder library code or bad unwind data
>>>>>>>>> emitted by gcc. (I sure hope it's the library, because that's easier to
>>>>>>>>> fix.)
>>>>>>>>>
>>>>>>>>> On the clang front, it has been said that c++ exceptions work in clang
>>>>>>>>> 3.5, so we tried the clang-devel port, and it didn't just work. But it
>>>>>>>>> turns out that port hasn't been updated for quite a while, so we may not
>>>>>>>>> have tested the code that's supposed to work right. While trying that I
>>>>>>>>> discovered that clang 3.5 isn't scheduled for release for about another
>>>>>>>>> year, so that really isn't a viable solution for anyone with near-term
>>>>>>>>> needs, unless the required changes can be cherry-picked and brought into
>>>>>>>>> our version of 3.4.
>>>>>>>>>
>>>>>>>>> -- Ian
>>>>>>>>
>>>>>>>> Another update to this... today I committed r268993 and r268994, and now
>>>>>>>> I believe arm eabi c++ exceptions are fully working with gcc. I haven't
>>>>>>>> run an extensive test suite, but all the test cases we've been using at
>>>>>>>> $work to debug this now work correctly.
>>>>>>>
>>>>>>> Thank you! Confirmed. My test cases which are working with gcc-4.10 are now also working with the system gcc, 4.2.1.
>>>>>>> I totally forgot about this change. I have it in my local gcc tree since a while but I forgot about.....
>>>>>>>
>>>>>>> Andreas
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Please excuse my late reply. I’ve been away from keyboard for a while.
>>>>>>
>>>>>> I back-ported r268893, r268993 and r268994 to stable/10 for beaglebone. C++ exceptions works for static builds, but not for binaries linked to shared libs.
>>>>>>
>>>>>> Since this seems to work ok in HEAD, I’m obviously missing something. Do any of you guys have any ideas?
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>
>>>>> I'm not sure what you mean by "backported to stable/10", I merged all
>>>>> the necessary changes to stable-10 as r269792 on Aug 10. Are you
>>>>> working with a checkout from earlier than that? If so, just updating
>>>>> should fix it for you.
>>>>>
>>>>> -- Ian
>>>>>
>>>>>
>>>>
>>>>
>>>> Updating to stable-10 as of today didn’t help. I’m running a clean checkout except for a couple of drivers in the kernel.
>>>> This makes me think I have a bad src.conf - How shall I configure the build for this to work?
>>>>
>>>> /Olavi
>>>>
>>>>
>>>>
>>>>
>>>
>>> You need to use GCC, not clang, as the compiler. Exceptions are just
>>> broken on clang 3.4, so we're waiting for 3.5 (should be released any
>>> time now I think).
>>>
>>> To compile with gcc, put this in your /etc/make.conf:
>>>
>>> WITH_GCC=yes
>>> WITH_GNUCXX=yes
>>> WITH_GCC_BOOTSTRAP=yes
>>> WITHOUT_CLANG=yes
>>> WITHOUT_CLANG_IS_CC=yes
>>> WITHOUT_CLANG_BOOTSTRAP=yes
>>>
>>> -- Ian
>>>
>>>
>>
>>
>> Thank you. It turned out that I already used these with the exception of WITHOUT_CLANG_BOOTSTRAP.
>>
>> However, c++ exceptions in stable/10 is still defunct when I build it.
>>
>> So instead I pulled master, built and installed that instead. And voila - Exceptions do work!
>>
>> Therefore it seems my build method, flags and environment is ok after all. I glanced the commit logs in master but didn’t find anything obvious, but still; something related seems missing in stable/10 if you ask me.
>>
>> /Olavi
>>
>>
>>
>> _______________________________________________
>> freebsd-arm at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>>
>
> I chased this down today to a missing MFC. One of my merges claimed to
> include a change that wasn't really included. I fixed it today with
> r270606, and this time I actually tested that I could throw and catch an
> exception using freebsd built from stable-10 at this rev. :)
>
> Thanks for testing this, and sorry for claiming it was fixed when it
> wasn't quite complete.
>
> -- Ian
>
>
I’m a little late again, but I still want to confirm that stable/10 works for me too. It catches c++ exceptions like a real champ!
Thanks a million -
/Olavi
More information about the freebsd-arm
mailing list