Date: Sat, 7 Jun 2014 19:13:41 +0200 From: Olavi Kumpulainen <olavi.m.kumpulainen@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org> Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work Message-ID: <F15D6589-ADBA-46F0-AB4B-2EDDE1192CD1@gmail.com> In-Reply-To: <0567DA73-DE37-48F0-BD18-F6498D6083A6@bsdimp.com> References: <BEAC4CFB-EC4F-456D-8173-2E34CCE3A2C1@gmail.com> <1402156516.20883.154.camel@revolution.hippie.lan> <CAJ-VmomsNogAzk8j6ob8aA%2BmJeiO5TEF=FQnq=mNzsVPyt23xw@mail.gmail.com> <EEBA06F7-0CF1-4712-BA61-5951323B541B@bsdimp.com> <CAJ-Vmo=7VSZQH8NGBvYN015cV7WGcA=S2ELdpnmk798y98ydSQ@mail.gmail.com> <0567DA73-DE37-48F0-BD18-F6498D6083A6@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07 Jun 2014, at 18:29 , Warner Losh <imp@bsdimp.com> wrote: >=20 > On Jun 7, 2014, at 10:24 AM, Adrian Chadd <adrian@freebsd.org> wrote: >=20 >> On 7 June 2014 12:14, Warner Losh <imp@bsdimp.com> wrote: >>>=20 >>> On Jun 7, 2014, at 10:07 AM, Adrian Chadd <adrian@FreeBSD.org> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F15D6589-ADBA-46F0-AB4B-2EDDE1192CD1>