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

[Ian Lepore]

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