Date: Tue, 22 Jul 2014 15:11:13 -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: <1406063473.71975.8.camel@revolution.hippie.lan> In-Reply-To: <1405809318.85788.35.camel@revolution.hippie.lan> References: <BEAC4CFB-EC4F-456D-8173-2E34CCE3A2C1@gmail.com> <1405809318.85788.35.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Even with these changes, exceptions still don't work in clang 3.4 or 3.5 (this time I used a very recent 3.5 checkout). I did notice that 3.4 and 3.5 emit virtually identical unwind data, so the problem is likely to be in library code. I'm not even sure we link with the right library code in the clang case; the problem may be trying to use gcc's exception and unwind code with clang's not-quite-compatible unwind data or something like that. Also, to correct misinformation in the quoted text above, clang 3.5 is apparently scheduled for release in summer 2014 (i.e., soon), not 2015 like I originally saw on some news site. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1406063473.71975.8.camel>