From owner-freebsd-arm@FreeBSD.ORG Fri Jul 25 21:44:39 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 1A096163; Fri, 25 Jul 2014 21:44:39 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (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 A386D2102; Fri, 25 Jul 2014 21:44:37 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s6PLiUNA054804; Fri, 25 Jul 2014 23:44:34 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53D2CFBE.3040207@fgznet.ch> Date: Fri, 25 Jul 2014 23:44:30 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work References: <1405809318.85788.35.camel@revolution.hippie.lan> <1406063473.71975.8.camel@revolution.hippie.lan> In-Reply-To: <1406063473.71975.8.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 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: Fri, 25 Jul 2014 21:44:39 -0000 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