Bug 56734 - Even simple exceptions cause a segmentation fault in my build of gcc on Solaris 10.
Summary: Even simple exceptions cause a segmentation fault in my build of gcc on Solar...
Status: RESOLVED DUPLICATE of bug 55909
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.7.2
: P3 major
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-26 07:52 UTC by Marc Girod
Modified: 2013-03-29 08:39 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
The object containing the throw and the catch (57.44 KB, application/octet-stream)
2013-03-26 07:52 UTC, Marc Girod
Details
the main function (137 bytes, application/octet-stream)
2013-03-26 07:53 UTC, Marc Girod
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Girod 2013-03-26 07:52:20 UTC
Created attachment 29725 [details]
The object containing the throw and the catch

gcc version 4.7.2 (GCC) 
Target: sparc-sun-solaris2.10
Configured with: /proj/vobadm100/svn/gcc_4.7.2/configure \
  --prefix /vobs/cello/cade_A_tools_gcc \
  --with-gnu-as --with-as=/vobs/cello/cade_A_tools_utils/binutils/bin/as \
  --with-gnu-ld --with-ld=/vobs/cello/cade_A_tools_utils/binutils/bin/ld \
  --enable-threads --enable-languages=c,c++,java \
  --with-gmp=/vobs/cello/cade_A_tools_utils/gmp \
  --with-mpfr=/vobs/cello/cade_A_tools_utils/mpfr \
  --with-mpc=/vobs/cello/cade_A_tools_utils/mpc \
  --with-isl=/vobs/cello/cade_A_tools_utils/isl

The command line is:

$ ./CoreTest
Segmentation Fault

It runs a small test case reproducing the problem.
I attach the two preprocessed sources: Core.ii and CoreTest.ii.
Here is the stack trace produced by gdb:

Starting program: /home/emagiro/tmp/shex/CoreTest 
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xff35af84 in __frame_dummy_init_array_entry ()
   from /vobs/cello/cade_struct/lib/libstdc++.so.6
(gdb) bt
#0  0xff35af84 in __frame_dummy_init_array_entry ()
   from /vobs/cello/cade_struct/lib/libstdc++.so.6
#1  0xff2c8b48 in __cxxabiv1::__cxa_get_globals ()
    at /proj/vobadm100/svn/gcc_4.7.2/libstdc++-v3/libsupc++/eh_globals.cc:63
#2  0xff2c7a10 in __cxxabiv1::__cxa_allocate_exception (thrown_size=135552)
    at /proj/vobadm100/svn/gcc_4.7.2/libstdc++-v3/libsupc++/eh_alloc.cc:132
#3  0x00010acc in ThrowException () at Core.cc:7
#4  0x00010a90 in main () at CoreTest.cc:4

I put the main function itno a separate file, but you want only one attachment...
The source is trivial anyway:

$ cat CoreTest.cc
#include "Core.h"

int main() {
    ThrowException();
    return 1;
}
Comment 1 Marc Girod 2013-03-26 07:53:46 UTC
Created attachment 29726 [details]
the main function
Comment 2 Mikael Pettersson 2013-03-26 09:09:18 UTC
Works for me on Solaris 2.10/SPARC, gcc-4.7.2 configured w/ Sun not GNU binutils:

> g++ -O -c Core.ii 
> g++ -O -c CoreTest.ii 
> g++ Core.o CoreTest.o 
> ./a.out 
Exception int caught

For completeness:

> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/mikpe/pkgs/sol2-sparc64/gcc-4.7.2/libexec/gcc/sparc-sun-solaris2.10/4.7.2/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: /tmp/mikpe/gcc-4.7.2/configure --prefix=/home/mikpe/pkgs/sol2-sparc64/gcc-4.7.2 --with-gmp=/home/mikpe/pkgs/sol2-sparc64/gmp-5.0.5 --with-mpfr=/home/mikpe/pkgs/sol2-sparc64/mpfr-3.1.1 --with-mpc=/home/mikpe/pkgs/sol2-sparc64/mpc-1.0.1 --disable-build-poststage1-with-cxx --disable-libquadmath --disable-plugin --disable-lto --disable-nls --disable-shared --disable-libmudflap --disable-libgomp --enable-threads --enable-checking=release --enable-version-specific-runtime-libs --with-system-zlib --enable-languages=c,c++,ada --with-cpu=ultrasparc --without-cloog --without-ppl
Thread model: posix
gcc version 4.7.2 (GCC)
Comment 3 Marc Girod 2013-03-27 06:52:14 UTC
OK. Good to know. I configured with GNU, hence there is something in the tool chain which results in the problem.
Under the debugger, I get the segfault stepping into the call to 'get_global()' in libstdc++-v3/libsupc++/eh_globals.cc:63.
I can find only one declaration of this get_global, and it is earlier in eh_globals.cc:50.
Looking at the decorations in the symbols:

gcc> nm ./sparc-sun-solaris2.10/libstdc++-v3/libsupc++/eh_globals.o
         U _GLOBAL_OFFSET_TABLE_
00000000 d _ZL16__gthread_active
00000000 b _ZZN12_GLOBAL__N_110get_globalEvE6global
00000000 T __cxa_get_globals
00000000 T __cxa_get_globals_fast
00000000 W __sparc_get_pc_thunk.l7
         U __tls_get_addr

I wonder if there is a mismatch between the offering and the request?
What symbols do you have, in the Sun configuration?
Note that I was handed another gcc, compiled independently for the same platform, and which displays the same issue.
Comment 4 Marc Girod 2013-03-27 07:00:33 UTC
Sorry: the other compiler works once I set LD_LIBRARY_PATH to use its libstdc++.so.6 and libgcc_s.so.1
Comment 5 Eric Botcazou 2013-03-27 10:22:44 UTC
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1 (LWP 1)]
> 0xff35af84 in __frame_dummy_init_array_entry ()
>    from /vobs/cello/cade_struct/lib/libstdc++.so.6
> (gdb) bt
> #0  0xff35af84 in __frame_dummy_init_array_entry ()
>    from /vobs/cello/cade_struct/lib/libstdc++.so.6
> #1  0xff2c8b48 in __cxxabiv1::__cxa_get_globals ()
>     at /proj/vobadm100/svn/gcc_4.7.2/libstdc++-v3/libsupc++/eh_globals.cc:63
> #2  0xff2c7a10 in __cxxabiv1::__cxa_allocate_exception (thrown_size=135552)
>     at /proj/vobadm100/svn/gcc_4.7.2/libstdc++-v3/libsupc++/eh_alloc.cc:132
> #3  0x00010acc in ThrowException () at Core.cc:7
> #4  0x00010a90 in main () at CoreTest.cc:4

This is a dup of PR target/55909 and might be related to PR binutils/15056:
  http://sourceware.org/bugzilla/show_bug.cgi?id=15056
which reports that TLS is broken for the SPARC in the 2.23.1 binutils release.

You need to upgrade to the just released 2.23.2 release of binutils.

*** This bug has been marked as a duplicate of bug 55909 ***
Comment 6 Marc Girod 2013-03-29 08:39:38 UTC
I can acknowledge that installing binutils 2.23.2 solved my problem with gcc 4.7.2