From owner-freebsd-arm@FreeBSD.ORG Tue Jul 22 21:11:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 276B485D for ; Tue, 22 Jul 2014 21:11:22 +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 ED786271C for ; Tue, 22 Jul 2014 21:11:21 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X9hL9-000Lmv-6E; Tue, 22 Jul 2014 21:11:15 +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 s6MLBEae035388; Tue, 22 Jul 2014 15:11:14 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 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/9LiAx+y7nlpNIh2oCdXEe 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: <1405809318.85788.35.camel@revolution.hippie.lan> References: <1405809318.85788.35.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Jul 2014 15:11:13 -0600 Message-ID: <1406063473.71975.8.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:11:22 -0000 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