Problem: -------- The GCC exception handling mechanism for powerpc-e500v2-linux-gnuspe seems to be broken. Every programs abort as soon as the first exception is thrown. I can confirm that the exception handling works on at least 4.6.3 and 4.7.4, however on 4.8.3 it does not. Example program to reproduce the problem: ----------------------------------------- #include <exception> #include <stdio.h> void doThrow() { printf("Throwing now\n"); throw std::exception(); } int main(int argc, char **argv) { try { doThrow(); } catch (std::exception& e) { printf("Caught exception\n"); } return 0; } GDB output: ----------- Program received signal SIGABRT, Aborted. 0x0fc0c858 in raise () from /lib/libc.so.6 (gdb) bt #0 0x0fc0c858 in raise () from /lib/libc.so.6 #1 0x0fc117c4 in abort () from /lib/libc.so.6 #2 0x0fd78250 in ?? () from /lib/libgcc_s.so.1 #3 0x0fd78960 in _Unwind_RaiseException () from /lib/libgcc_s.so.1 #4 0x0ff33e0c in __cxa_throw () from /lib/libstdc++.so.6 #5 0x100007dc in doThrow() () #6 0x10000800 in main () (gdb) GCC version: ------------ The compiler has been compiled with crosstool-ng: ./powerpc-e500v2-linux-gnuspe-gcc -v Using built-in specs. COLLECT_GCC=./powerpc-e500v2-linux-gnuspe-gcc COLLECT_LTO_WRAPPER=/opt/x-tools/tron/4.8.3/powerpc-e500v2-linux-gnuspe/bin/../libexec/gcc/powerpc-e500v2-linux-gnuspe/4.8.3/lto-wrapper Target: powerpc-e500v2-linux-gnuspe Configured with: /home/manrud00/crosstool-ng/.build/src/gcc-4.8.3/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=powerpc-e500v2-linux-gnuspe --prefix=/home/manrud00/x-tools/powerpc-e500v2-linux-gnuspe --with-sysroot=/home/manrud00/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/sysroot --enable-languages=c,c++ --with-cpu=8548 --with-tune=8548 --with-pkgversion='crosstool-NG hg+default-99029fac116b' --disable-sjlj-exceptions --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --with-gmp=/home/manrud00/crosstool-ng/.build/powerpc-e500v2-linux-gnuspe/buildtools --with-mpfr=/home/manrud00/crosstool-ng/.build/powerpc-e500v2-linux-gnuspe/buildtools --with-mpc=/home/manrud00/crosstool-ng/.build/powerpc-e500v2-linux-gnuspe/buildtools --with-isl=/home/manrud00/crosstool-ng/.build/powerpc-e500v2-linux-gnuspe/buildtools --with-cloog=/home/manrud00/crosstool-ng/.build/powerpc-e500v2-linux-gnuspe/buildtools --with-libelf=/home/manrud00/crosstool-ng/.build/powerpc-e500v2-linux-gnuspe/buildtools --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix --disable-nls --disable-multilib --with-local-prefix=/home/manrud00/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/sysroot --enable-c99 --enable-long-long --enable-e500_double --with-long-double-128 Thread model: posix gcc version 4.8.3
Cannot reproduce this with neither 4.9.2 nor 5.0 (20141123) for powerpc-e500v2-linux-gnuspe.
I've built 4.9.2 today and can also confirm that it is working with this version, so it seems the bug has already been fixed in newer GCC versions.
I was probably to enthusiastic, the problem is still there, even in GCC 4.9.2. In order to reproduce the bug, you either have to use a root file system which was also built with GCC 4.8.3 or 4.9.2, or you just link the example program statically (which is probably the easier thing). The problem does not seem to be in the generated binary of the compiler, but in one of the used libs (probably libgcc_s.so). So when I link statically with the "-static" option, I got this stacktrace in gdb: Program received signal SIGABRT, Aborted. 0x1003d28c in raise () (gdb) bt #0 0x1003d28c in raise () #1 0x10018e1c in abort () #2 0x100100bc in uw_init_context_1 () #3 0x10010cdc in _Unwind_RaiseException () #4 0x10001db4 in __cxa_throw () at /home/manrud00/crosstool-ng/.build/src/gcc-4.9.2/libstdc++-v3/libsupc++/eh_throw.cc:82 #5 0x10000c94 in doThrow() () at exception.cpp:14 #6 0x10000cb8 in main () at exception.cpp:21
It's a known issue: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02625.html and https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02605.html have the complete fix I think.
(In reply to manfred.rudigier from comment #3) > In order to reproduce the bug, you either have to use a root file > system which was also built with GCC 4.8.3 or 4.9.2, or you just link the > example program statically (which is probably the easier thing). My root file system was built w/ 4.10.0 snapshot back in March when it hadn't yet diverged significantly from 4.9, so it's hardly a requirement. I'll try however to link the test case statically in Monday.
(In reply to manfred.rudigier from comment #3) > I was probably to enthusiastic, the problem is still there, even in GCC > 4.9.2. In order to reproduce the bug, you either have to use a root file > system which was also built with GCC 4.8.3 or 4.9.2, or you just link the > example program statically (which is probably the easier thing). OK, when I've built the program statically I reproduced the issue.
GCC 4.8.4 has been released.
(In reply to Jakub Jelinek from comment #7) > GCC 4.8.4 has been released. I have tried out GCC 4.8.4 today, but it still has this issue.
Sure it has. The fix wasn't committed to the tree, otherwise it would be reported here.
Created attachment 34317 [details] Backport cfispan.diff to gcc-4.8.3 Attempt to backport cfispan.diff from https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02625/cfispan.diff referenced from comment #4 here, to gcc-4.8.3 which we are using for ppc e500v2 So far as I've been able to determine so far, it works for us, passing the repro mentioned elsewhere in this bug and also the similar repro I had developed, and not introducing other unexpected changes. In combination with the msg2504.html backport also attached. gcc-4.8.4 code in the vicinity of this patch is nearly identical with 4.8.3.
Created attachment 34318 [details] Backport msg02605 patch to gcc-4.8.3 Apply after other attachment
I have a backport of the patches referenced in comment 4, which I applied to the gcc-4.8.3 we are using for e500v2. If anybody would care to look at it, comment whether it has any merit at all, try it etc, I'd be honored.
(In reply to Dan Wilder from comment #12) > I have a backport of the patches referenced in comment 4, which I applied to > the gcc-4.8.3 we are using for e500v2. If anybody would care to look at it, > comment whether it has any merit at all, try it etc, I'd be honored. I have applied your backported patches to gcc 4.8.4 and can confirm that they fix this issue. Thanks!
I have the same problem with 5.1 on a 603e, even though the patches from comment #4 seem to have been applied. I get the same stack trace as seen in comment #3. It doesn't matter whether I compile with --with-cpu=603e or without.
Any problem seen on 603e is a different issue from this (fixed) e500-specific issue and should not be discussed in this bug.
Sorry, Joseph, I wasn't sure if this issue was fixed or not since the status is "NEW". I'll report a new issue.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
Fixed.