Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 07 Jun 2014 09:55:16 -0600
From:      Ian Lepore <ian@FreeBSD.org>
To:        Olavi Kumpulainen <olavi.m.kumpulainen@gmail.com>
Cc:        freebsd-arm@FreeBSD.org
Subject:   Re: C++ exceptions in freebsd-arm doesn't seem to work
Message-ID:  <1402156516.20883.154.camel@revolution.hippie.lan>
In-Reply-To: <BEAC4CFB-EC4F-456D-8173-2E34CCE3A2C1@gmail.com>
References:  <BEAC4CFB-EC4F-456D-8173-2E34CCE3A2C1@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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=FFt find an=
ything when scanning through the archives though.
>=20
> So, I=FFm running FreeBSD-10/stable on a RPI version B as you can see h=
ere;
>=20
>=20
> Copyright (c) 1992-2014 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199=
4
>         The Regents of the University of California. All rights reserve=
d.
> 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) 2014051=
2
>=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 << =B4In 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=FFve tried debugging this for a couple of days and have concluded tha=
t my throw clause ends up in contrib/gcc/config/arm/unwind-arm.c. The ass=
ociated 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 th=
e call
>      instruction itself.  */
>   return_address -=3D 2;
>=20
>   if (__gnu_Unwind_Find_exidx)
>     {
>       eitp =3D (const __EIT_entry *) __gnu_Unwind_Find_exidx (return_ad=
dress,
> 							    &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 arr=
ay located between __exidx_start and __exidx_end.
>=20
> However, __exidx_end =3D=3D __exidx_start! So the EIT has a length of z=
ero, 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 err=
or 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=FFt seem to work.
>=20
> Can any of you guys shed some light on this?
>=20
> Cheers,
>=20
> /Olavi

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.

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.

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1402156516.20883.154.camel>