From owner-freebsd-arm@FreeBSD.ORG Wed Aug 20 19:19:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 174BC7C1 for ; Wed, 20 Aug 2014 19:19:56 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C765E3BC8 for ; Wed, 20 Aug 2014 19:19:55 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XKBQH-000IIu-Ng; Wed, 20 Aug 2014 19:19:53 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s7KJJq15054150; Wed, 20 Aug 2014 13:19:52 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+mmhKEKuhlp5cuC6fQRBu5 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Ian Lepore To: Olavi Kumpulainen In-Reply-To: References: <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> Content-Type: text/plain; charset="iso-8859-7" Date: Wed, 20 Aug 2014 13:19:52 -0600 Message-ID: <1408562392.1150.4.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s7KJJq15054150 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 19:19:56 -0000 On Wed, 2014-08-20 at 19:19 +0200, Olavi Kumpulainen wrote: > On 19 Aug 2014, at 20:21 , Ian Lepore wrote: >=20 > > On Tue, 2014-08-19 at 19:40 +0200, Olavi Kumpulainen wrote: > >> On 25 Jul 2014, at 23:44 , Andreas Tobler = 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 essentia= lly > >>>>> that the __gnu_Unwind_Find_exidx() function was not available in = any > >>>>> shared library, making the unwinder fall back to using the __exid= x_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 thing= s 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 segfau= lts, > >>>>> but a catch(...) will catch it without problems. But you can cat= ch an > >>>>> exception by type if the catch is in a function higher up the cal= l 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 wheth= er 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 ea= sier 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 a= nother > >>>>> year, so that really isn't a viable solution for anyone with near= -term > >>>>> needs, unless the required changes can be cherry-picked and broug= ht into > >>>>> our version of 3.4. > >>>>>=20 > >>>>> -- Ian > >>>>=20 > >>>> Another update to this... today I committed r268993 and r268994, a= nd now > >>>> I believe arm eabi c++ exceptions are fully working with gcc. I h= aven't > >>>> run an extensive test suite, but all the test cases we've been usi= ng 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 wh= ile. > >>=20 > >> I back-ported r268893, r268993 and r268994 to stable/10 for beagleb= one. 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 somethi= ng. 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 b= uild for this to work? >=20 > /Olavi >=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). To compile with gcc, put this in your /etc/make.conf: WITH_GCC=3Dyes WITH_GNUCXX=3Dyes WITH_GCC_BOOTSTRAP=3Dyes WITHOUT_CLANG=3Dyes WITHOUT_CLANG_IS_CC=3Dyes WITHOUT_CLANG_BOOTSTRAP=3Dyes -- Ian