C++ exceptions in freebsd-arm doesn't seem to work

[Olavi Kumpulainen]

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
> 
> 

I pulled from github on the 8th of August which is why I missed r269792. My "backport patches" seems identical to yours though.

But better safe than sorry, I’ll sync with stable-10 tomorrow.

Thanks -

/Olavi