From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 17:13:47 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 21D9482F; Sat, 7 Jun 2014 17:13:47 +0000 (UTC) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 3E18A2FDC; Sat, 7 Jun 2014 17:13:46 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id w7so2235501lbi.15 for ; Sat, 07 Jun 2014 10:13:44 -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=DkJ75+5gQmZjh5cnfCkVK7FAkOKvF57ijf4TTVRWDLU=; b=bGTv2seW4IFaE9datQDaRR4glmxvdYOyV34B77zAeizqJyXNwkkxtjvfcip2KIW2Uh nNsorapAfFiSZqnx953uf7sZndh8dzsZC7F9X/6GLQOdFZDCcZVVYE1jz10Ve3DIaQ2E hzzQ7u2N0j6bu8Nfjhun68hon/xgrmOvg8nInn7LZB3B/WKJ5awKCxD4gA3JWO+JyFgI eYLMYdiGy2Tpx/5j3u1DX2VIUBXWRQwErMFDCabK4ZxogsODkzMi7sNdu1tJ1yNr/e2g LITl1LHf2dKFCt5SFoUEyDZ4kWt5i5e87PMh/RdxBSQIStYq72TzpO0IrEWAmnoeMjlT sNAA== X-Received: by 10.152.4.227 with SMTP id n3mr9503923lan.16.1402161224116; Sat, 07 Jun 2014 10:13:44 -0700 (PDT) Received: from [192.168.1.106] (c-3535e155.556-1-64736c11.cust.bredbandsbolaget.se. [85.225.53.53]) by mx.google.com with ESMTPSA id oc3sm12471920lbb.18.2014.06.07.10.13.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 10:13:43 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Olavi Kumpulainen In-Reply-To: <0567DA73-DE37-48F0-BD18-F6498D6083A6@bsdimp.com> Date: Sat, 7 Jun 2014 19:13:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1402156516.20883.154.camel@revolution.hippie.lan> <0567DA73-DE37-48F0-BD18-F6498D6083A6@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" , Ian Lepore 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: Sat, 07 Jun 2014 17:13:47 -0000 On 07 Jun 2014, at 18:29 , Warner Losh wrote: >=20 > On Jun 7, 2014, at 10:24 AM, Adrian Chadd wrote: >=20 >> On 7 June 2014 12:14, Warner Losh wrote: >>>=20 >>> On Jun 7, 2014, at 10:07 AM, Adrian Chadd = wrote: >>>=20 >>>>> Sadly, all I can do is confirm what you say: C++ exceptions don't = work >>>>> on ARM EABI, not with clang and not with gcc. The only combo that = works >>>>> is gcc and OABI, but with that combo you lose hardware floating = point. >>>>>=20 >>>>> There are rumours that this may be fixed in clang 3.5, but we = apparently >>>>> can't import 3.5 because it can't be bootstrapped using gcc 4.2. = I >>>>> haven't had time yet to learn how to build clang 3.5 out-of-tree = to >>>>> confirm that exceptions work there. >>>>>=20 >>>>=20 >>>> If only we had a way to tell our build system to build the = in-src-tree >>>> compiler suite using an external compiler toolchain. That'd make = those >>>> problems go away. >>>=20 >>> We do. It isn=92t perfect, and you=92d have to bootstrap either a = new gcc or a 3.4 clang first to do it though. The automation of the = bootstrapping isn=92t present, and is what I=92m working on=85 >>=20 >> Cool! The last time I wrangled this, I could only get it to build the >> whole system with the compiler I fed in. It wouldn't build the >> in-source-tree compiler with the external compiler I gave it - using >> the external compiler seemed to totally just negate building the >> toolchain. I'm glad this isn't the case. >=20 > It does take many hand-stands to doit... >=20 >>> Of course, it doesn=92t solve all the problems, just means we have = more tools to deploy. >>>=20 >>> 3.5 is also quite experimental as well. >>>=20 >>> But there=92s been no real talk about the right path forward: just = FUD and hand wringing on the lists. We do need to have a real discussion = about this. Not the lame pot-shots that have happened to date: what = versions do we support upgrading from, what configurations, etc. If we = had that discussion, then we wouldn=92t even need what Adrian suggests. = We=92d just say you have to have FreeBSD 9.2 or newer with clang 3.3 (or = is it clang 3.4) to bootstrap, and if you want to use other tools, you = are on your own. This would break updating from 8.x, but that=92s likely = OK. Be we need to have this discussion. >>=20 >> I'd personally like to rehash the "build from under Linux" = discussion. >> I keep bumping into cases like this where a lot of the work being = done >> to make this stuff happen is in line with what we need to be able to >> build FreeBSD under a non-FreeBSD operating system. I'd really like >> _that_ to happen - it'll help migrations _to_ freebsd from other >> projects. >=20 > No. Have that as a separate discussion. That=92s a big bike shed of = wonder and requires functionality not present in the tree (e.g. actual = work). My discussion is =93we currently allow X to work, I want to = change that to X+Y so we can import Z.=94 which is much smaller. So go = ahead and have your linux discussion, but don=92t hijack mine. >=20 > Warner Thanks guys, A =93no=94 is also an answer and it seems I have to work-around my = throw-catch=92es with setjmp/longjmp for the time being.=20 As for "This would break updating from 8.x, but that=92s likely OK.=94 - = I totally agree with that it=92s OK. I think function has precedence = over legacy support.=20 Understand me correctly now. Legacy support _is_ important. It=92s just = that current function is _more_ important.=20 At the moment we have a system that doesn=92t support c++ exceptions, = this is a serious limitation. It means that we=92re not standard = compliant. This will likely make tentative developers disappointed. Most (all?) = RPI/beaglebone developers would not care whether their systems was = upgradeable from FreeBSD-8 or not.=20 /Olavi