Date: Sun, 20 Jul 2014 10:46:59 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work Message-ID: <E10A3A5A-D23C-49B7-91AD-1C8231B50663@bsdimp.com> In-Reply-To: <1405817348.85788.53.camel@revolution.hippie.lan> References: <BEAC4CFB-EC4F-456D-8173-2E34CCE3A2C1@gmail.com> <1402156516.20883.154.camel@revolution.hippie.lan> <0591C8AC-22F9-45FC-B959-10FACF8C05C1@bsdimp.com> <1405817348.85788.53.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <ian@FreeBSD.org> wrote:
> On Sat, 2014-07-19 at 18:20 -0600, Warner Losh wrote:
>> On Jun 7, 2014, at 9:55 AM, Ian Lepore <ian@FreeBSD.org> 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 <stdexcept>
>>>> #include <iostream>
>>>>=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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E10A3A5A-D23C-49B7-91AD-1C8231B50663>