Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Jul 2014 18:20:04 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Ian Lepore <ian@FreeBSD.org>
Cc:        freebsd-arm@FreeBSD.org, Olavi Kumpulainen <olavi.m.kumpulainen@gmail.com>
Subject:   Re: C++ exceptions in freebsd-arm doesn't seem to work
Message-ID:  <0591C8AC-22F9-45FC-B959-10FACF8C05C1@bsdimp.com>
In-Reply-To: <1402156516.20883.154.camel@revolution.hippie.lan>
References:  <BEAC4CFB-EC4F-456D-8173-2E34CCE3A2C1@gmail.com> <1402156516.20883.154.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_5A457760-F9C8-4CD9-BD6F-C99DEB039BD7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Jun 7, 2014, at 9:55 AM, Ian Lepore <ian@FreeBSD.org> wrote:

> 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=B4t find =
anything when scanning through the archives though.
>>=20
>> So, I=B4m 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 << =93In 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=B4ve 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=B4t 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.

I=92d like to make one thing perfectly clear, as there=92s some =
confusion.
As long as we can bootstrap from the last version of the system, the
fact that it doesn=92t compile with gcc 4.2 is *NOT* a gating factor. =
That=92s
never been a requirement for a 3.5 import, and gcc 4.2 is being shown
the door for 11.x.

I=92ve 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.

Warner

--Apple-Mail=_5A457760-F9C8-4CD9-BD6F-C99DEB039BD7
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

iQIcBAEBCgAGBQJTyws0AAoJEGwc0Sh9sBEAYuIP/ixtLDJ/6N7cXSKeWp9fKgxv
teZ3jBOcBiMlos4NJQ9gj3VLtBcz6QkpQ+SgcjXLlBmJPfDn9RRtvhwUY6jD0gXi
eaDo+K0QuNLlrYgNORhkQAEgz9ZjAB0bSQBM1lzqZAyLV4T5QAwf9VQIXj+MUu+p
7GZ53QERqG6Da9eFlkBCUgw8drNiIy96FRo1P6XI6SNLPx56x6LTnanaYhP4ZxDw
0PQqLqF356/MwfhPtJXP4vK+DXSYqtmCCm1+11QUpNEo5WWvJktKk1rJ6wc8qB19
DtCgZqUjgroYiUf740Iz1dTvJ0l0YtTp41eusmxyLtJ1gPnSYa5SEUyhU4OlHH0v
yV/qvmuQAi5xEQMgB2tP4kdlyO9I7sG9cyZ2QDdsa5lUg5z8XgXlGuTgyr4mddKv
lxgf93gjU6RiV0R18VhisY1TgsLjefmwF7J1QBwUAXXH5qbnnJVIATdhYHShWUnA
9RjoBKvJhgOUyk51/XfeeHtuvgnW2+5VP2sUrFEvI+2nqxrEFvqqg2sYHZSL1baK
kzTl/lEwouXyFFzBlglsEWEmdrB9LAJ2w0FGxOO7G+TVm+A2eSWr0CJbhtipu/23
CIQlNJKFWGMDWCT11vAvGobtM9nxARdm5bFq8WP/rDfiZ00dbp2x2NyairnV+d41
b4aeAyh98uylS1DoZHqc
=K55l
-----END PGP SIGNATURE-----

--Apple-Mail=_5A457760-F9C8-4CD9-BD6F-C99DEB039BD7--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0591C8AC-22F9-45FC-B959-10FACF8C05C1>