From owner-freebsd-arm@FreeBSD.ORG Sun Jul 20 16:46:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5D3F1FC for ; Sun, 20 Jul 2014 16:46:57 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (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 7A1E42500 for ; Sun, 20 Jul 2014 16:46:57 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id rl12so6108038iec.38 for ; Sun, 20 Jul 2014 09:46:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=a7nlK/Rp2FPou1TXmFSxZCk2CNiMWAZLi+ujUtdCUzs=; b=XYyouB5+liUvlf/Q4m+P4icbZ+T/d2Dpv6JcHjMw2gTTC9/m8xSMQnyl38kyZD6CJ+ jBuOMVNigX6/NlPb9HEz9I6JHZlvKLsZ1M1Xwq80nGSLd/rKPmj1cVFGgjXUOqFas2yY c7t3BZ2hvXvPx1e2bf6Qc+9mJSwe3ADLm4f0G2H0VamSHxNMQJnHJAnecrIGannYjfUB oOO2h/7pTAF+c20Xa647xGzMYe16ehQGh6l7T8h2e65QiDFAHT6Uytyh+36+W/ehcsLu BegU6oAE5ZW3YK6zs/K2Ly9zbF7/F1yvK9qrWs+G9chTq7a6aXWQAnEstA8NwKYqtQxF dJCg== X-Gm-Message-State: ALoCoQnpYPlCrNIZWXQ1MBFNe25brDtwYx5x7QKY+To3nGzZX5Il1ztPXTkVe39fI6W1yqad7VpO X-Received: by 10.50.134.106 with SMTP id pj10mr1311537igb.25.1405874815952; Sun, 20 Jul 2014 09:46:55 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id j5sm29743988ige.12.2014.07.20.09.46.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jul 2014 09:46:55 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_7A32CB17-D7A7-4BB1-97BF-56F1D97E1B29"; protocol="application/pgp-signature"; micalg=pgp-sha512 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: Warner Losh In-Reply-To: <1405817348.85788.53.camel@revolution.hippie.lan> Date: Sun, 20 Jul 2014 10:46:59 -0600 Message-Id: References: <1402156516.20883.154.camel@revolution.hippie.lan> <0591C8AC-22F9-45FC-B959-10FACF8C05C1@bsdimp.com> <1405817348.85788.53.camel@revolution.hippie.lan> 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 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 16:46:57 -0000 --Apple-Mail=_7A32CB17-D7A7-4BB1-97BF-56F1D97E1B29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp On Jul 19, 2014, at 6:49 PM, Ian Lepore wrote: > On Sat, 2014-07-19 at 18:20 -0600, Warner Losh wrote: >> On Jun 7, 2014, at 9:55 AM, Ian Lepore wrote: >>=20 >>> On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: >>>> Hi there, >>>>=20 >>>> If this question has been discussed before, sorry. I = couldn=1B$B!-=1B(Bt find anything when scanning through the archives = though. >>>>=20 >>>> So, I=1B$B!-=1B(Bm running FreeBSD-10/stable on a RPI version B as = you can see here; >>>>=20 >>>>=20 >>>> Copyright (c) 1992-2014 The FreeBSD Project. >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >>>> The Regents of the University of California. All rights = reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 10.0-STABLE #0 r266807: Thu May 29 07:07:08 UTC 2014 >>>> root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >>>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 >>>>=20 >>>>=20 >>>> I have this little program; >>>>=20 >>>> $ cat t.cc >>>>=20 >>>> #include >>>> #include >>>>=20 >>>> void func()=20 >>>> { >>>> throw std::exception(); >>>> } >>>>=20 >>>>=20 >>>> int main() >>>> { >>>> std::cout << "Starting throw-test" << std::endl; >>>>=20 >>>> try >>>> { >>>> func(); >>>> } >>>> catch(std::exception){ >>>> std::cout << =1B$B!H=1B(BIn my exception handler" << = std::endl; >>>> } >>>> catch(...) { >>>> std::cout << "In catch-all handler" << std::endl; >>>> } >>>>=20 >>>> return 0; >>>> } >>>>=20 >>>> With this Makefile; >>>>=20 >>>> $ cat Makefile >>>>=20 >>>> all : t >>>>=20 >>>> t : t.cc >>>> c++ -o t -fexceptions t.cc >>>>=20 >>>>=20 >>>> Running the above produces the following result; >>>>=20 >>>> $ ./t >>>> Starting throw-test >>>> Fatal error during phase 1 unwinding >>>> Abort (core dumped) >>>>=20 >>>> Which indeed is not what I expected. >>>>=20 >>>> I=1B$B!-=1B(Bve tried debugging this for a couple of days and have = concluded that my throw clause ends up in = contrib/gcc/config/arm/unwind-arm.c. The associated code in unwind-arm.c = is; >>>>=20 >>>> static _Unwind_Reason_Code >>>> get_eit_entry (_Unwind_Control_Block *ucbp, _uw return_address) >>>> { >>>> const __EIT_entry * eitp; >>>> int nrec; >>>>=20 >>>> /* The return address is the address of the instruction following = the >>>> call instruction (plus one in thumb mode). If this was the last >>>> instruction in the function the address will lie in the = following >>>> function. Subtract 2 from the address so that it points within = the call >>>> instruction itself. */ >>>> return_address -=3D 2; >>>>=20 >>>> if (__gnu_Unwind_Find_exidx) >>>> { >>>> eitp =3D (const __EIT_entry *) __gnu_Unwind_Find_exidx = (return_address, >>>> &nrec); >>>> if (!eitp) >>>> { >>>> UCB_PR_ADDR (ucbp) =3D 0; >>>> return _URC_FAILURE; >>>> } >>>> } >>>> else >>>> { >>>> eitp =3D &__exidx_start; >>>> nrec =3D &__exidx_end - &__exidx_start; >>>> } >>>>=20 >>>>=20 >>>> Since __gnu_Unwind_Find_exidx =3D=3D NULL, the EIT is located in an = array located between __exidx_start and __exidx_end. >>>>=20 >>>> However, __exidx_end =3D=3D __exidx_start! So the EIT has a length = of zero, nrec will be 0. libgcc will fail the lookup and return = _URC_FAILURE to libcxxrt.cc, which in turn will produce the = fprintf(stderr, "Fatal error during phase 1 unwinding\n"); >>>>=20 >>>> # readelf -s t | grep exidx >>>> 36: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start >>>> 47: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end >>>> 115: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end >>>> 150: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start >>>>=20 >>>> So exception throwing in clang++ doesn=1B$B!-=1B(Bt seem to work. >>>>=20 >>>> Can any of you guys shed some light on this? >>>>=20 >>>> Cheers, >>>>=20 >>>> /Olavi >>>=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 >> I=1B$B!G=1B(Bd like to make one thing perfectly clear, as = there=1B$B!G=1B(Bs some confusion. >> As long as we can bootstrap from the last version of the system, the >> fact that it doesn=1B$B!G=1B(Bt compile with gcc 4.2 is *NOT* a = gating factor. That=1B$B!G=1B(Bs >> never been a requirement for a 3.5 import, and gcc 4.2 is being shown >> the door for 11.x. >>=20 >> I=1B$B!G=1B(Bve not had time to try it either. And my time for doing = build stuff has >> been limited the past month or so. I hope to get back to it in the = coming >> weeks to resolve some lingering issues, as well as fix the external >> toolchain support to be completely bootstrapping rather than half >> bootstrapping like we have today. >>=20 >> Warner >=20 > I was under the mistaken impression that 3.5 had been released but we > hadn't adopted it yet. Yesterday I saw something that said 3.5 is > scheduled for release in summer 2015, but I think that was a typo on a > news site. Looking deeper just now, it appears to be scheduled for > August 2014. Hopefully when released, it will be mature enough for us to include in = 11. Warner --Apple-Mail=_7A32CB17-D7A7-4BB1-97BF-56F1D97E1B29 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTy/KDAAoJEGwc0Sh9sBEAYKwP/Apqo3gtg0pPFQmuOkyQKwOq +4eFpw8snENE3Hk3rQST8cW6FdaaAUyR2u6RJkl/2n9gv0ak5qFlkEErG/X1HNYB dS7ANANwGom1Gq3BxnDHtYT1bftH2W754qRhNTrglJpzg1zEt0Pb3hSHRQqTSoJt gywoFNiSY2uG9COEUL+VZru9IAIv7gYJlYh4OvNGUYj51OcshWiek0635jSowyME 3jt2otRvaJdheb880pglPmIb7phFO8CjpBBw/pADRUF2YHgeqGv98dHrM6BpdP0X eQZ3JDJGVLMySgGMn1/Xw8Fj9x3SwySRLddzx5wXKaGhPar8IO2bxcwlPrnTePyJ 4GouVPvn6f4hljvXsimVWfE7daNxAxgmJ4WDNfXwxe7r22BCrasWaY9tLymX9Kur 7g94tOJSJLrRM1yzk8HDF8ZiMtyVYblQ4Ceh7CMDmNc4to4Ar/yJan/hm5N8zqS5 HqUiQeFxH/XnlnCku2c1Q/wPdi8rs9TDnse8rp2+mxwsUw+qIjbk5DPscaCudeAq BK3r2RU1jFAl2g9yTAQAIgvakdmtMB/yls9vrSPvDgzGKEIEFYtmDTEP2BeZElZ9 V7oBeTl1WOQKk7A91mVK+huD/gbiWSOlrYbz2J0aq1Kr43fP3oVZDROXz6gi/FBW 85yLWrIgu1VcDuVo9SGb =9+Q9 -----END PGP SIGNATURE----- --Apple-Mail=_7A32CB17-D7A7-4BB1-97BF-56F1D97E1B29--