Date: Sat, 20 Feb 2016 16:17:32 -0800 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, Roman Divacky <rdivacky@vlakno.cz> Cc: Dimitry Andric <dim@FreeBSD.org> Subject: Questions, powerpc/powerpc64 clang 3.8.0/libc++ buildworld context: which _Unwind_RaiseException implementation(s)? Message-ID: <94F068B6-48FA-477A-AE12-5558C2C22F7E@dsl-only.net>
next in thread | raw e-mail | index | archive | help
Anyone know for clang 3.8.0 or devel/powerpc64-gcc based and =
WITH_LIBCPLUSPLUS=3D (use of libcxxrt and libc++ for the system) which =
_Unwind_RaiseException implementation is supposed to be used for =
TARGET_ARCH=3Dpowerpc? TARGET_ARCH=3Dpowerpc64? Alternatives around =
include:
/usr/src/contrib/llvm/projects/libunwind/src/Unwind-EHABI.cpp having:
> _Unwind_RaiseException(_Unwind_Exception *exception_object) {
/usr/src/contrib/llvm/projects/libunwind/src/UnwindLevel1.c having:
> _Unwind_RaiseException(_Unwind_Exception *exception_object) {
/usr/src/contrib/gcc/unwind.inc having:
> _Unwind_RaiseException(struct _Unwind_Exception *exc)
Should contrib/libcxxrt/exception.cc in a clang 3.8.0/libc++ or =
devel/powerpc64-gcc based buildworld context ever use =
contrib/gcc/unwind.inc's _Unwind_RaiseException implementation?
For both TARGET_ARCH=3Dpowerpc (clang 3.8.0 based buildworld) and =
TARGET_ARCH=3Dpowerpc64 (devel/powerpc64-gccb based buildworld) I =
currently get the contrib/gcc/unwind.inc binding.
But c++ exceptions fail to work for both contexts:
TARGET_ARCH=3Dpowerpc gets a SEGV in _Unwind_GetGR
(contrib/gcc/unwind-dw2.c:177).
TARGET_ARCH=3Dpowerpc64 loops without bound in _Unwind_RaiseException
(in contrib/gcc/unwind.inc).
For TARGET_ARCH=3Dpowerpc using a different compiler than clang 3.8.0:
> # g++5 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic =
exception_test.cpp
> or
> # g++5 -g -Wall -pedantic exception_test.cpp
> or
> # g++49 -g -Wall -pedantic exception_test.cpp
> or
> # g++49 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic =
exception_test.cpp
(Note the lack of -Wl,-rpath=3D/usr/local/lib/gcc49 or =
-Wl,-rpath=3D/usr/local/lib/gcc5 use.)
I get the same SEGV at the same place (return statement in =
_unwind_GetGR) despite the use of _Unwind_Resume_or_Rethrow being the =
caller of _Unwind_RaiseException (backtrace omitted here):
> # ./a.out
> terminate called after throwing an instance of 'std::exception'
> Segmentation fault (core dumped)
By contrast the following do not fail:
> # g++49 -Wl,-rpath=3D/usr/local/lib/gcc49 -g -Wall -pedantic =
exception_test.cpp
> # ./a.out
> # g++5 -Wl,-rpath=3D/usr/local/lib/gcc5 -g -Wall -pedantic =
exception_test.cpp
> # ./a.out
> #=20
For TARGET_ARCH=3Dpowerpc64 (devel/powerpc64-gcc is already gcc5 based =
but has no /usr/local/lib/gcc5/ so just using lang/gcc49):
> # g++49 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic =
exception_test.cpp
I get the same "loops without bound in _Unwind_RaiseException" as with =
clang++ and devel/powerpc64-gcc.
But for:
> # g++49 -Wl,-rpath=3D/usr/local/lib/gcc49 -g -Wall -pedantic =
exception_test.cpp
the ./a.out works fine for the powerpc64 context.
All this suggests problems in contrib/gcc/ for stack unwinding for =
powerpc and for powerpc64 for each of the g++49, g++5, and clang 3.8.0 =
compilers.
Some sort of exception-ABI difference(s) with gcc 4.2.1 for each of the =
2 TARGET_ARCH's and more modern compilers?
Note that for powerpc64 buildworld was done by devel/powerpc64-gcc, not =
by clang 3.8.0, vastly limiting clang's involvement. Yet a problem still =
exists.
The following 8 line program is enough to show the behavior:
> #include <exception>
>=20
> int main(void)
> {
> try { throw std::exception(); }
> catch (std::exception& e) {} // same result without &
> return 0;
> }
But the original problem was found and isolated in kyua and other =
programs before generating the simple example.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94F068B6-48FA-477A-AE12-5558C2C22F7E>