Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
Richard Henderson r...@redhat.com writes:
On 01/25/2012 12:03 AM, Rainer Orth wrote:
Er.. how did we get two copies?
The link line boils down to
ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc
-lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o
The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder
from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1,
providing another copy.
So... are we linking with the gcc binary, not the g++ binary?
Because I thought -shared-libgcc is the default for C++.
If this goes too far down a rat-hole, your original patch is ok.
The compiler used is currently set in libitm.exp (libitm_init) without
considering the language used. Changing this seems too risky for
stage4. I think we can get away with the following patch instead, which
hardcodes -shared-libgcc for C++. I think it is safe even with
--disable-shared since -shared-libgcc is simply ignored AFAICS, and is
already used unconditionally in libffi.special/special.exp.
Tested on i386-pc-solaris2.11.
Ok for mainline?
Rainer
2012-01-28 Rainer Orth r...@cebitec.uni-bielefeld.de
PR libstdc++/51296
* testsuite/libitm.c++/c++.exp (lang_link_flags): Add
-shared-libgcc.
Correct libgomp references.
# HG changeset patch
# Parent 707821cb5b73761684848cdd143b741881b067ce
Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
diff --git a/libitm/testsuite/libitm.c++/c++.exp b/libitm/testsuite/libitm.c++/c++.exp
--- a/libitm/testsuite/libitm.c++/c++.exp
+++ b/libitm/testsuite/libitm.c++/c++.exp
@@ -1,3 +1,5 @@
+# Copyright (C) 2011, 2012 Free Software Foundation, Inc.
+#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
@@ -17,14 +19,16 @@ load_lib libitm-dg.exp
global shlib_ext
set shlib_ext [get_shlib_extension]
-set lang_link_flags -lstdc++
+# The C++ tests should be linked with g++, which defaults to -shared-libgcc.
+# Doing that is currently too intrusive, so hardcode here.
+set lang_link_flags -shared-libgcc -lstdc++
set lang_test_file_found 0
set lang_library_path ../libstdc++-v3/src/.libs
# Initialize dg.
dg-init
-set blddir [lookfor_file [get_multilibs] libgomp]
+set blddir [lookfor_file [get_multilibs] libitm]
if { $blddir != } {
@@ -41,7 +45,7 @@ if { $blddir != } {
}
} elseif { [info exists GXX_UNDER_TEST] } {
set lang_test_file_found 1
-# Needs to exist for libgomp.exp.
+# Needs to exist for libitm.exp.
set lang_test_file
} else {
puts GXX_UNDER_TEST not defined, will not execute c++ tests
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
On Mon, Jan 30, 2012 at 05:40:21PM +0100, Rainer Orth wrote:
Richard Henderson r...@redhat.com writes:
On 01/25/2012 12:03 AM, Rainer Orth wrote:
Er.. how did we get two copies?
The link line boils down to
ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc
-lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o
The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder
from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1,
providing another copy.
So... are we linking with the gcc binary, not the g++ binary?
Because I thought -shared-libgcc is the default for C++.
If this goes too far down a rat-hole, your original patch is ok.
The compiler used is currently set in libitm.exp (libitm_init) without
considering the language used. Changing this seems too risky for
stage4. I think we can get away with the following patch instead, which
hardcodes -shared-libgcc for C++. I think it is safe even with
--disable-shared since -shared-libgcc is simply ignored AFAICS, and is
already used unconditionally in libffi.special/special.exp.
Tested on i386-pc-solaris2.11.
FYI, this fix has no impact on the eh-1.C execution failures seen at -m32/-m64
on x86_64 darwin10/11
when built with Xcode 4.2(.1).
Ok for mainline?
Rainer
2012-01-28 Rainer Orth r...@cebitec.uni-bielefeld.de
PR libstdc++/51296
* testsuite/libitm.c++/c++.exp (lang_link_flags): Add
-shared-libgcc.
Correct libgomp references.
# HG changeset patch
# Parent 707821cb5b73761684848cdd143b741881b067ce
Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
diff --git a/libitm/testsuite/libitm.c++/c++.exp
b/libitm/testsuite/libitm.c++/c++.exp
--- a/libitm/testsuite/libitm.c++/c++.exp
+++ b/libitm/testsuite/libitm.c++/c++.exp
@@ -1,3 +1,5 @@
+# Copyright (C) 2011, 2012 Free Software Foundation, Inc.
+#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
@@ -17,14 +19,16 @@ load_lib libitm-dg.exp
global shlib_ext
set shlib_ext [get_shlib_extension]
-set lang_link_flags -lstdc++
+# The C++ tests should be linked with g++, which defaults to -shared-libgcc.
+# Doing that is currently too intrusive, so hardcode here.
+set lang_link_flags -shared-libgcc -lstdc++
set lang_test_file_found 0
set lang_library_path ../libstdc++-v3/src/.libs
# Initialize dg.
dg-init
-set blddir [lookfor_file [get_multilibs] libgomp]
+set blddir [lookfor_file [get_multilibs] libitm]
if { $blddir != } {
@@ -41,7 +45,7 @@ if { $blddir != } {
}
} elseif { [info exists GXX_UNDER_TEST] } {
set lang_test_file_found 1
-# Needs to exist for libgomp.exp.
+# Needs to exist for libitm.exp.
set lang_test_file
} else {
puts GXX_UNDER_TEST not defined, will not execute c++ tests
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
On 01/30/2012 12:15 PM, Jack Howarth wrote: On Mon, Jan 30, 2012 at 05:40:21PM +0100, Rainer Orth wrote: Richard Hendersonr...@redhat.com writes: On 01/25/2012 12:03 AM, Rainer Orth wrote: Er.. how did we get two copies? The link line boils down to ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1, providing another copy. So... are we linking with the gcc binary, not the g++ binary? Because I thought -shared-libgcc is the default for C++. If this goes too far down a rat-hole, your original patch is ok. The compiler used is currently set in libitm.exp (libitm_init) without considering the language used. Changing this seems too risky for stage4. I think we can get away with the following patch instead, which hardcodes -shared-libgcc for C++. I think it is safe even with --disable-shared since -shared-libgcc is simply ignored AFAICS, and is already used unconditionally in libffi.special/special.exp. Tested on i386-pc-solaris2.11. FYI, this fix has no impact on the eh-1.C execution failures seen at -m32/-m64 on x86_64 darwin10/11 when built with Xcode 4.2(.1). Problem was discussed here and not same problem as above: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00285.html -- Patrick.
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
Jack Howarth howa...@bromo.med.uc.edu writes: FYI, this fix has no impact on the eh-1.C execution failures seen at -m32/-m64 on x86_64 darwin10/11 when built with Xcode 4.2(.1). Then you need to do the analysis why exactly the failure occurs in this case. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
On 01/31/2012 03:40 AM, Rainer Orth wrote: 2012-01-28 Rainer Orth r...@cebitec.uni-bielefeld.de PR libstdc++/51296 * testsuite/libitm.c++/c++.exp (lang_link_flags): Add -shared-libgcc. Correct libgomp references. Ok. r~
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
On Mon, Jan 30, 2012 at 12:24:07PM -0500, Patrick Marlier wrote: On 01/30/2012 12:15 PM, Jack Howarth wrote: On Mon, Jan 30, 2012 at 05:40:21PM +0100, Rainer Orth wrote: Richard Hendersonr...@redhat.com writes: On 01/25/2012 12:03 AM, Rainer Orth wrote: Er.. how did we get two copies? The link line boils down to ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1, providing another copy. So... are we linking with the gcc binary, not the g++ binary? Because I thought -shared-libgcc is the default for C++. If this goes too far down a rat-hole, your original patch is ok. The compiler used is currently set in libitm.exp (libitm_init) without considering the language used. Changing this seems too risky for stage4. I think we can get away with the following patch instead, which hardcodes -shared-libgcc for C++. I think it is safe even with --disable-shared since -shared-libgcc is simply ignored AFAICS, and is already used unconditionally in libffi.special/special.exp. Tested on i386-pc-solaris2.11. FYI, this fix has no impact on the eh-1.C execution failures seen at -m32/-m64 on x86_64 darwin10/11 when built with Xcode 4.2(.1). Problem was discussed here and not same problem as above: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00285.html Patrick, My mistake. The issue on darwin with Xcode 4.x will either require avoiding the use of weakref for darwin or assuming that the user will either use Xcode 3.x or a future fixed Xcode 4.x release. I am told the weakref linker bug is fixed upstream but won't make it into Xcode 4.3 (so it is currently unknown when this fix will be available for Lion). Jack -- Patrick.
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
Richard Henderson r...@redhat.com writes: The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1, providing another copy. So... are we linking with the gcc binary, not the g++ binary? Right. This was just copied over from libgomp, like most of the libitm build and test framework. Because I thought -shared-libgcc is the default for C++. Indeed: manually replacing xgcc with g++ in the link line fixes the test, and is certainly far better than a per-platform per-test workaround. I'll see what it takes to properly fix that. If this goes too far down a rat-hole, your original patch is ok. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
Richard Henderson r...@redhat.com writes: On 01/17/2012 04:07 AM, Rainer Orth wrote: * The 32-bit failures on Solaris 8 to 10 have a different root cause: _Unwind_Find_FDE returns NULL for an address in _ZGTtL2f1v (f1()). It turns out that there are two copies of the unwinder in eh-1.exe: one from libgcc_s.so.1, and another one from libgcc_eh.a. eh-1.o has a reference to _Unwind_Resume (don't yet know why), which is resolved from libgcc_eh.a. This doesn't happen on Solaris 11, which uses the dl_iterate_phdr based unwinder, thus no __register_frame_info_bases. Er.. how did we get two copies? The link line boils down to ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1, providing another copy. I don't think this change is correct, as it seems just as likely that we'd hit the same problem with real applications. This just seems like it's papering over the real problem. Quite possible. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
On 01/25/2012 12:03 AM, Rainer Orth wrote: Er.. how did we get two copies? The link line boils down to ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1, providing another copy. So... are we linking with the gcc binary, not the g++ binary? Because I thought -shared-libgcc is the default for C++. If this goes too far down a rat-hole, your original patch is ok. r~
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
On 01/17/2012 04:07 AM, Rainer Orth wrote: * The 32-bit failures on Solaris 8 to 10 have a different root cause: _Unwind_Find_FDE returns NULL for an address in _ZGTtL2f1v (f1()). It turns out that there are two copies of the unwinder in eh-1.exe: one from libgcc_s.so.1, and another one from libgcc_eh.a. eh-1.o has a reference to _Unwind_Resume (don't yet know why), which is resolved from libgcc_eh.a. This doesn't happen on Solaris 11, which uses the dl_iterate_phdr based unwinder, thus no __register_frame_info_bases. Er.. how did we get two copies? I don't think this change is correct, as it seems just as likely that we'd hit the same problem with real applications. This just seems like it's papering over the real problem. r~
[libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
As reported in PR libitm/51822, the libitm.c++/eh-1.C test FAILs on
Solaris with
terminate called after throwing an instance of 'int'
I found that the failures are for two different reasons:
* Enabling ld.so.1 debugging (LD_DEBUG=bindings), it turned out that the
64-bit failures on Solaris 10 and 11 happen since
_Unwind_RaiseException from libc is used:
25243: 1: binding file=../../../gcc/amd64/libgcc_s.so.1
(0xfd7fc21e6910:0x16910) at plt[27]:full to file=/lib/64/libc.so.1
(0xfd7fff05a250:0x12a250): symbol '_Unwind_RaiseException'
Unlike SPARC and the 32-bit libc, the 64-bit one provides an
implementation of the unwinder, which seems to break this test.
Linking the test with -shared-libgcc fixes it.
* The 32-bit failures on Solaris 8 to 10 have a different root cause:
_Unwind_Find_FDE returns NULL for an address in _ZGTtL2f1v (f1()). It
turns out that there are two copies of the unwinder in eh-1.exe: one
from libgcc_s.so.1, and another one from libgcc_eh.a. eh-1.o has a
reference to _Unwind_Resume (don't yet know why), which is resolved
from libgcc_eh.a. This doesn't happen on Solaris 11, which uses the
dl_iterate_phdr based unwinder, thus no __register_frame_info_bases.
Again, linking with shared-libgcc allows the testcase to succeed.
Bootstrapped without regressions on i386-pc-solaris2.11.
Ok for mainline?
Rainer
2012-01-15 Rainer Orth r...@cebitec.uni-bielefeld.de
PR libitm/51822
* testsuite/libitm.c++/eh-1.C: Add -shared-libgcc on *-*-solaris2*.
# HG changeset patch
# Parent b41d70648bc4d3ba4c7930a694c0100973a1ed01
Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
diff --git a/libitm/testsuite/libitm.c++/eh-1.C b/libitm/testsuite/libitm.c++/eh-1.C
--- a/libitm/testsuite/libitm.c++/eh-1.C
+++ b/libitm/testsuite/libitm.c++/eh-1.C
@@ -1,4 +1,5 @@
// { dg-do run }
+// { dg-options -shared-libgcc { target *-*-solaris2* } }
extern C void abort ();
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
