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 Henderson 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)
On 01/31/2012 03:40 AM, Rainer Orth wrote: > 2012-01-28 Rainer Orth > > 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)
Jack Howarth 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/30/2012 12:15 PM, Jack Howarth wrote: On Mon, Jan 30, 2012 at 05:40:21PM +0100, Rainer Orth wrote: Richard Henderson 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)
On Mon, Jan 30, 2012 at 05:40:21PM +0100, Rainer Orth wrote:
> Richard Henderson 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
>
> 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)
Richard Henderson 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
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)
Richard Henderson 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)
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)
Richard Henderson 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/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
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
