[libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)

[libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]

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 (0xfffffd7fc21e6910:0x16910) at plt[27]:full to file=/lib/64/libc.so.1 (0xfffffd7fff05a250: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  <ro@CeBiTec.Uni-Bielefeld.DE>

	PR libitm/51822
	* testsuite/libitm.c++/eh-1.C: Add -shared-libgcc on *-*-solaris2*.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sol2-libitm-eh-1.patch --]
[-- Type: text/x-patch, Size: 428 bytes --]

# 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 ();
 

[-- Attachment #3: Type: text/plain, Size: 144 bytes --]



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

Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)

[Richard Henderson]

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~

Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)

[Rainer Orth]

Richard Henderson <rth@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)

[Richard Henderson]

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)

[Rainer Orth]

Richard Henderson <rth@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)

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

Richard Henderson <rth@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  <ro@CeBiTec.Uni-Bielefeld.DE>

	PR libstdc++/51296
	* testsuite/libitm.c++/c++.exp (lang_link_flags): Add
	-shared-libgcc.
	Correct libgomp references.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sol2-libitm-eh-1.patch --]
[-- Type: text/x-patch, Size: 1459 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 144 bytes --]



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

Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)

[Jack Howarth]

On Mon, Jan 30, 2012 at 05:40:21PM +0100, Rainer Orth wrote:
> Richard Henderson <rth@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  <ro@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)

[Patrick Marlier]

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<rth@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)

[Rainer Orth]

Jack Howarth <howarth@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)

[Richard Henderson]

On 01/31/2012 03:40 AM, Rainer Orth wrote:
> 2012-01-28  Rainer Orth  <ro@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)

[Jack Howarth]

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<rth@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.