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

[Olavi Kumpulainen]

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

/Olavi