Support enforcing use of libgcc_s even with LINK_EH_SPEC

[Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>]

For the last two weeks, testsuite results on Solaris 11/x86 with gld
2.21.1 have been terrible, which hundreds of link failures.  One example
is

spawn /var/gcc/regression/trunk/11-gcc-gas-gld/build/gcc/xgcc -B/var/gcc/regression/trunk/11-gcc-gas-gld/build/gcc/ /vol/gcc/src/hg/trunk/local/libffi/testsuite/libffi.call/closure_fn0.c -O0 -W -Wall -I/var/gcc/regression/trunk/11-gcc-gas-gld/build/i386-pc-solaris2.11/./libffi/include -I/vol/gcc/src/hg/trunk/local/libffi/testsuite/../include -I/var/gcc/regression/trunk/11-gcc-gas-gld/build/i386-pc-solaris2.11/./libffi/include/.. -L/var/gcc/regression/trunk/11-gcc-gas-gld/build/i386-pc-solaris2.11/./libffi/.libs -L/var/gcc/regression/trunk/11-gcc-gas-gld/build/i386-pc-solaris2.11/./libstdc++-v3/src/.libs -lffi -lm -o ./closure_fn0.exe
/vol/gcc/bin/gld-2.21.1: .compiler exited with status 1
output is:
/vol/gcc/bin/gld-2.21.1: .
FAIL: libffi.call/closure_fn0.c -O0 -W -Wall (test for excess errors)
Excess errors:
/vol/gcc/bin/gld-2.21.1: .
WARNING: libffi.call/closure_fn0.c -O0 -W -Wall compilation failed to produce executable

Executing this manually gives:

/vol/gcc/bin/gld-2.21.1: ./closure_fn0.exe: hidden symbol `__gcc_personality_v0' in /var/gcc/regression/trunk/11-gcc-gas-gld/build/gcc/libgcc_eh.a(unwind-c.o) is referenced by DSO
/vol/gcc/bin/gld-2.21.1: final link failed: Bad value
collect2: error: ld returned 1 exit status

The message could certainly be improved here!  (It turns out the DSO in
question is libffi.so.)

I've still to investigate where this bad pruning stems from, but the
problem boils down to the following: since this patch

2011-11-08  Michael Matz  <matz@suse.de>

	* gengtype.c (write_field_root): Avoid out-of-scope access of newv.

	* tree-stdarg.c (execute_optimize_stdarg): Accept clobbers.
[...]

several of the target libraries developed references to
__gcc_personality_v0, which weren't there before.  The executable is
linked like this:

 /var/gcc/regression/trunk/11-gcc-gas-gld/build/gcc/collect2 --eh-frame-hdr -V -m elf_i386_sol2 -Y P,/usr/ccs/lib:/lib:/usr/lib -Qy -o ./closure_fn0.exe /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/values-Xa.o /var/gcc/regression/trunk/11-gcc-gas-gld/build/gcc/crtbegin.o -L/var/gcc/regression/trunk/11-gcc-gas-gld/build/i386-pc-solaris2.11/./libffi/.libs -L/var/gcc/regression/trunk/11-gcc-gas-gld/build/i386-pc-solaris2.11/./libstdc++-v3/src/.libs -L/var/gcc/regression/trunk/11-gcc-gas-gld/build/gcc closure_fn0.o -lffi -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /var/gcc/regression/trunk/11-gcc-gas-gld/build/gcc/crtend.o /usr/lib/crtn.o

i.e. only with libgcc_eh.a, where __gcc_personality_v0 is hidden.

The problem is that (unlike with ld), libffi.so isn't linked with
libgcc_s.so.1 because gcc.c (init_spec) decides that if LINK_EH_SPEC is
defined, this mustn't/needn't be done.  I've no idea why this should be
so, but hacked around it by forcing to always use libgcc_s with -shared
as in the patch below.  This brought testsuite results with gld much
more in line with Sun ld results, but most likely isn't appropriate, or
at the very least needs the FIXME comment filled in and documentation in
tm.texi.

One could of course also link all affected target libraries with an
explicit -shared-libgcc (as is already done for e.g. libobjc and
libstdc++).

Suggestions?

	Rainer


2011-11-20  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* gcc.c (init_gcc_specs) [USE_SHARED_LIBGCC_FOR_EH]: Always use
	libgcc_s.
	* config/sol2.h [USE_GLD] (USE_SHARED_LIBGCC_FOR_EH): Define.

# HG changeset patch
# Parent 0f811d11987fd90895cf6fda7698d876e59f39a5
Support enforcing use of libgcc_s even with LINK_EH_SPEC

diff --git a/gcc/config/sol2.h b/gcc/config/sol2.h
--- a/gcc/config/sol2.h
+++ b/gcc/config/sol2.h
@@ -182,6 +182,8 @@ along with GCC; see the file COPYING3.  
    --eh-frame-hdr to create the required .eh_frame_hdr sections.  */
 #if defined(HAVE_LD_EH_FRAME_HDR) && defined(TARGET_DL_ITERATE_PHDR)
 #define LINK_EH_SPEC "%{!static:--eh-frame-hdr} "
+/* Always use libgcc_s.  FIXME: Why?  */
+#define USE_SHARED_LIBGCC_FOR_EH 1
 #endif /* HAVE_LD_EH_FRAME && TARGET_DL_ITERATE_PHDR */
 #endif
 
diff --git a/gcc/gcc.c b/gcc/gcc.c
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1291,7 +1291,7 @@ init_gcc_specs (struct obstack *obstack,
 		"%{!shared-libgcc:", static_name, " ", eh_name, "}"
 		"%{shared-libgcc:", shared_name, " ", static_name, "}"
 		"}"
-#ifdef LINK_EH_SPEC
+#if defined(LINK_EH_SPEC) && !USE_SHARED_LIBGCC_FOR_EH
 		"%{shared:"
 		"%{shared-libgcc:", shared_name, "}"
 		"%{!shared-libgcc:", static_name, "}"


-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University