Date: Thu, 21 Aug 2014 18:54:49 +0200 From: Olavi Kumpulainen <olavi.m.kumpulainen@gmail.com> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@freebsd.org Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work Message-ID: <2C97B126-91FE-4E93-920F-6ED5045666A6@gmail.com> In-Reply-To: <1408562392.1150.4.camel@revolution.hippie.lan> 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> <1408472517.56408.659.camel@revolution.hippie.lan> <F4EE79A6-9D99-4EE1-9452-2C7ECF963646@gmail.com> <1408562392.1150.4.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20 Aug 2014, at 21:19 , Ian Lepore <ian@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@FreeBSD.org> wrote: >>=20 >>> 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: >>>>=20 >>>>> 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] >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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.) >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> -- Ian >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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..... >>>>>=20 >>>>> Andreas >>>>>=20 >>>>>=20 >>>>=20 >>>> Please excuse my late reply. I=A2ve been away from keyboard for a = while. >>>>=20 >>>> 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. >>>>=20 >>>> Since this seems to work ok in HEAD, I=A2m obviously missing = something. Do any of you guys have any ideas? >>>>=20 >>>> Cheers >>>>=20 >>>=20 >>> 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. >>>=20 >>> -- Ian >>>=20 >>>=20 >>=20 >>=20 >> Updating to stable-10 as of today didn=A2t help. I=A2m 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? >>=20 >> /Olavi >>=20 >>=20 >>=20 >>=20 >=20 > 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). >=20 > To compile with gcc, put this in your /etc/make.conf: >=20 > WITH_GCC=3Dyes > WITH_GNUCXX=3Dyes > WITH_GCC_BOOTSTRAP=3Dyes > WITHOUT_CLANG=3Dyes > WITHOUT_CLANG_IS_CC=3Dyes > WITHOUT_CLANG_BOOTSTRAP=3Dyes >=20 > -- Ian >=20 >=20 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.=20= So instead I pulled master, built and installed that instead. And voila = - Exceptions do work!=20 Therefore it seems my build method, flags and environment is ok after = all. I glanced the commit logs in master but didn=A2t find anything = obvious, but still; something related seems missing in stable/10 if you = ask me. /Olavi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2C97B126-91FE-4E93-920F-6ED5045666A6>