Date: Tue, 19 Aug 2014 12:21:57 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Olavi Kumpulainen <olavi.m.kumpulainen@gmail.com> Cc: freebsd-arm@freebsd.org Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work Message-ID: <1408472517.56408.659.camel@revolution.hippie.lan> In-Reply-To: <834BA562-84ED-425C-9D61-0A235A28A94A@gmail.com> References: <BEAC4CFB-EC4F-456D-8173-2E34CCE3A2C1@gmail.com> <1405809318.85788.35.camel@revolution.hippie.lan> <1406063473.71975.8.camel@revolution.hippie.lan> <53D2CFBE.3040207@fgznet.ch> <834BA562-84ED-425C-9D61-0A235A28A94A@gmail.com>
index | next in thread | previous in thread | raw e-mail
On Tue, 2014-08-19 at 19:40 +0200, Olavi Kumpulainen wrote: > On 25 Jul 2014, at 23:44 , Andreas Tobler <andreast-list@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. -- Ianhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1408472517.56408.659.camel>