Bug 62231 - [4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
Summary: [4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.8.3
: P4 normal
Target Milestone: 5.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-22 13:31 UTC by manfred.rudigier
Modified: 2016-08-03 11:11 UTC (History)
2 users (show)

See Also:
Host:
Target: powerpc-e500v2-linux-gnuspe
Build:
Known to work: 4.6.3, 4.7.4, 5.0
Known to fail: 4.8.3, 4.8.4, 4.9.2, 4.9.4
Last reconfirmed: 2014-11-28 00:00:00


Attachments
Backport cfispan.diff to gcc-4.8.3 (1.66 KB, patch)
2014-12-22 23:38 UTC, Dan Wilder
Details | Diff
Backport msg02605 patch to gcc-4.8.3 (387 bytes, patch)
2014-12-22 23:42 UTC, Dan Wilder
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description manfred.rudigier 2014-08-22 13:31:19 UTC
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
Comment 1 Arseny Solokha 2014-11-27 05:16:34 UTC
Cannot reproduce this with neither 4.9.2 nor 5.0 (20141123) for powerpc-e500v2-linux-gnuspe.
Comment 2 manfred.rudigier 2014-11-27 08:35:17 UTC
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.
Comment 3 manfred.rudigier 2014-11-28 12:53:25 UTC
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
Comment 4 Eric Botcazou 2014-11-28 17:20:00 UTC
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.
Comment 5 Arseny Solokha 2014-11-28 17:26:45 UTC
(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.
Comment 6 Arseny Solokha 2014-12-01 12:42:04 UTC
(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.
Comment 7 Jakub Jelinek 2014-12-19 13:25:08 UTC
GCC 4.8.4 has been released.
Comment 8 manfred.rudigier 2014-12-22 08:55:40 UTC
(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.
Comment 9 Arseny Solokha 2014-12-22 12:21:36 UTC
Sure it has. The fix wasn't committed to the tree, otherwise it would be reported here.
Comment 10 Dan Wilder 2014-12-22 23:38:40 UTC
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.
Comment 11 Dan Wilder 2014-12-22 23:42:32 UTC
Created attachment 34318 [details]
Backport msg02605 patch to gcc-4.8.3

Apply after other attachment
Comment 12 Dan Wilder 2014-12-22 23:43:26 UTC
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.
Comment 13 manfred.rudigier 2014-12-23 09:43:41 UTC
(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!
Comment 14 Andri Yngvason 2015-05-19 18:01:14 UTC
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.
Comment 15 jsm-csl@polyomino.org.uk 2015-05-19 20:08:11 UTC
Any problem seen on 603e is a different issue from this (fixed) 
e500-specific issue and should not be discussed in this bug.
Comment 16 Andri Yngvason 2015-05-20 09:40:56 UTC
Sorry, Joseph, I wasn't sure if this issue was fixed or not since the status is "NEW". I'll report a new issue.
Comment 17 Richard Biener 2015-06-23 08:13:55 UTC
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
Comment 18 Jakub Jelinek 2015-06-26 19:52:01 UTC
GCC 4.9.3 has been released.
Comment 19 Richard Biener 2016-08-03 11:11:48 UTC
Fixed.