From owner-freebsd-arm@FreeBSD.ORG Tue Aug 19 17:41:03 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 0573CEAF; Tue, 19 Aug 2014 17:41:03 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 526C53AFA; Tue, 19 Aug 2014 17:41:02 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id l4so5772154lbv.2 for ; Tue, 19 Aug 2014 10:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KcLvJ0fWZXNUlN8aaO0iyvzErsEKtnwJpQvdpZZBN8U=; b=f/2LYFzz3Mo13hrV5wMOataXf9XMC5WQbse2vKsd0F+lcYvlY4uIdBIh4f8nmZwRM5 CQcbJAbre1f40CFw+5y7ffrI1jXNiQErBPt32+tetFcC71NLGbzUmoTN6j4z1YG2G13u MjWYO6MU380rjZYnreZPX/ONsV80GYWIzKuLilh1ITeU2d2XFv5wPEyXgSV/CnLibx3U i79PL1rK5z+MRSjMdCMH22dsomZVDnW/LhK7c3GG1/TKXcAUYsDNK9zFZqwRm7uTbo+G 1QLtVHSPOi19VwJOLRDbo2YeRccwzu1DX4mVo8wqWA/ul6f3pt77xbjupRize6gKcW5g D4Pg== X-Received: by 10.152.206.98 with SMTP id ln2mr37896204lac.45.1408470060234; Tue, 19 Aug 2014 10:41:00 -0700 (PDT) Received: from [192.168.1.105] (c-d135e155.556-1-64736c11.cust.bredbandsbolaget.se. [85.225.53.209]) by mx.google.com with ESMTPSA id dm6sm33039781lbc.31.2014.08.19.10.40.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 10:40:59 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Olavi Kumpulainen In-Reply-To: <53D2CFBE.3040207@fgznet.ch> Date: Tue, 19 Aug 2014 19:40:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <834BA562-84ED-425C-9D61-0A235A28A94A@gmail.com> References: <1405809318.85788.35.camel@revolution.hippie.lan> <1406063473.71975.8.camel@revolution.hippie.lan> <53D2CFBE.3040207@fgznet.ch> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) 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: Tue, 19 Aug 2014 17:41:03 -0000 On 25 Jul 2014, at 23:44 , Andreas Tobler = wrote: > 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 Please excuse my late reply. I=92ve been away from keyboard for a while. 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. Since this seems to work ok in HEAD, I=92m obviously missing something. = Do any of you guys have any ideas? Cheers /Olavi