diff mbox

Support enforcing use of libgcc_s even with LINK_EH_SPEC

Message ID yddbos5xwcl.fsf@manam.CeBiTec.Uni-Bielefeld.DE
State New
Headers show

Commit Message

Rainer Orth Nov. 21, 2011, 4:40 p.m. UTC 
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.

Comments

Jakub Jelinek Nov. 21, 2011, 5:47 p.m. UTC | #1 
On Mon, Nov 21, 2011 at 05:40:26PM +0100, Rainer Orth wrote:
> 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.

That's an ugly hack.  IMHO we just want to do what has been discussed
earlier, ensure that generated EH info and code generation isn't actually
pessimized because of the clobbers, at least not in the common cases.

	Jakub
Michael Matz Nov. 22, 2011, 1:23 p.m. UTC | #2 
Hi,

On Mon, 21 Nov 2011, Jakub Jelinek wrote:

> On Mon, Nov 21, 2011 at 05:40:26PM +0100, Rainer Orth wrote:
> > 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.
> 
> That's an ugly hack.  IMHO we just want to do what has been discussed
> earlier, ensure that generated EH info and code generation isn't actually
> pessimized because of the clobbers, at least not in the common cases.

I'm working on something that will hopefully work for the outermost 
finally block.  But it won't be ready today.


Ciao,
Michael.
diff mbox

Patch

# 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, "}"