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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
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,
>>
>> If this question has been discussed before, sorry. I couldn´t find anything when scanning through the archives though.
>>
>> So, I´m running FreeBSD-10/stable on a RPI version B as you can see here;
>>
>>
>> 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
>>
>>
>> I have this little program;
>>
>> $ cat t.cc
>>
>> #include <stdexcept>
>> #include <iostream>
>>
>> void func()
>> {
>> throw std::exception();
>> }
>>
>>
>> int main()
>> {
>> std::cout << "Starting throw-test" << std::endl;
>>
>> try
>> {
>> func();
>> }
>> catch(std::exception){
>> std::cout << “In my exception handler" << std::endl;
>> }
>> catch(...) {
>> std::cout << "In catch-all handler" << std::endl;
>> }
>>
>> return 0;
>> }
>>
>> With this Makefile;
>>
>> $ cat Makefile
>>
>> all : t
>>
>> t : t.cc
>> c++ -o t -fexceptions t.cc
>>
>>
>> Running the above produces the following result;
>>
>> $ ./t
>> Starting throw-test
>> Fatal error during phase 1 unwinding
>> Abort (core dumped)
>>
>> Which indeed is not what I expected.
>>
>> I´ve 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;
>>
>> static _Unwind_Reason_Code
>> get_eit_entry (_Unwind_Control_Block *ucbp, _uw return_address)
>> {
>> const __EIT_entry * eitp;
>> int nrec;
>>
>> /* 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 -= 2;
>>
>> if (__gnu_Unwind_Find_exidx)
>> {
>> eitp = (const __EIT_entry *) __gnu_Unwind_Find_exidx (return_address,
>> &nrec);
>> if (!eitp)
>> {
>> UCB_PR_ADDR (ucbp) = 0;
>> return _URC_FAILURE;
>> }
>> }
>> else
>> {
>> eitp = &__exidx_start;
>> nrec = &__exidx_end - &__exidx_start;
>> }
>>
>>
>> Since __gnu_Unwind_Find_exidx == NULL, the EIT is located in an array located between __exidx_start and __exidx_end.
>>
>> However, __exidx_end == __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");
>>
>> # 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
>>
>> So exception throwing in clang++ doesn´t seem to work.
>>
>> Can any of you guys shed some light on this?
>>
>> Cheers,
>>
>> /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.
I’d like to make one thing perfectly clear, as there’s some confusion.
As long as we can bootstrap from the last version of the system, the
fact that it doesn’t compile with gcc 4.2 is *NOT* a gating factor. That’s
never been a requirement for a 3.5 import, and gcc 4.2 is being shown
the door for 11.x.
I’ve 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
[-- Attachment #2 --]
-----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-----
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0591C8AC-22F9-45FC-B959-10FACF8C05C1>