exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Matthias Klose]

Noticed that some symbols introduced for the exception propagation support are
missing in libstdc++.so.6 on arm-linux-gnueabi, hppa-linux-gnu and
sparc-linux-gnu (no results for mips*-linux yet). The libstdc++ configure check
GLIBCXX_ENABLE_ATOMIC_BUILTINS fails, because three of the five __sync_*
functions are still seen in the asm code (not seen: __sync_lock_release and
__sync_synchronise).

libgcc.a has all of the __sync_* functions defined, and the configure (link)
tests in libgomp and libgfortran do succeed. Unsure what I'm doing wrong with
the libstdc++ configury. Is this seen on other linux builds for these targets as
well?

  Matthias

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Il giorno 02/mag/09, alle ore 13:05, Matthias Klose <doko@ubuntu.com>  
ha scritto:

> Noticed that some symbols introduced for the exception propagation  
> support are
> missing in libstdc++.so.6 on arm-linux-gnueabi, hppa-linux-gnu and
> sparc-linux-gnu (no results for mips*-linux yet). The libstdc++  
> configure check
> GLIBCXX_ENABLE_ATOMIC_BUILTINS fails, because three of the five  
> __sync_*
> functions are still seen in the asm code (not seen:  
> __sync_lock_release and
> __sync_synchronise).
>
> libgcc.a has all of the __sync_* functions defined, and the  
> configure (link)
> tests in libgomp and libgfortran do succeed. Unsure what I'm doing  
> wrong with
> the libstdc++ configury. Is this seen on other linux builds for  
> these targets as
> well?
>
>  Matthias

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Hi,

> libgcc.a has all of the __sync_* functions defined, and the  
> configure (link)
> tests in libgomp and libgfortran do succeed. Unsure what I'm doing  
> wrong with
> the libstdc++ configury.

I don't think you are doing anything wrong, it's just that in libstdc+ 
+ we are moving away from doing link tests. In my understanding, that  
would be nice also for the other libraries but of course leads yo  
weaker tests. Now, in order to make progress, I think we should first  
figure out if and to what extent we have now a libgcc such that  the  
atomic builtins can be assumed to be unconditionally available to the  
user, thus either expanded inline or provided on all the supported  
targets in libgcc. Besides that, we could maybe add a configure time  
option to tell the library to just assume the availability of the  
atomic builtins, thus not relying on weak compile-type tests. We could  
also add safe special cases to the configury, like assuming all the  
linux targets are now ok, one way or another.

I would appreciate some guidance from Mark and core compiler people,  
here...

To end, just want to remind that this issue is essentially very old,  
just less to the fore now thanks to the fact that x86_64 is so  
popular: eg, it woul be so nice if people targeting i?86 could assume  
the builtins to be always available.

Paolo

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Joseph S. Myers]

On Sat, 2 May 2009, Paolo Carlini wrote:

> I don't think you are doing anything wrong, it's just that in libstdc++ we are
> moving away from doing link tests. In my understanding, that would be nice
> also for the other libraries but of course leads yo weaker tests. Now, in
> order to make progress, I think we should first figure out if and to what
> extent we have now a libgcc such that  the atomic builtins can be assumed to
> be unconditionally available to the user, thus either expanded inline or
> provided on all the supported targets in libgcc. Besides that, we could maybe
> add a configure time option to tell the library to just assume the
> availability of the atomic builtins, thus not relying on weak compile-type
> tests. We could also add safe special cases to the configury, like assuming
> all the linux targets are now ok, one way or another.

Linux targets *don't* necessarily have the __sync_* functions.  For 
example, they are not available on ColdFire (even with Maxim's TLS patch 
which I imagine will be updated and reposted in due course now we are in 
Stage 1), since atomic operations there use a kernel helper in a vDSO.  It 
would be possible for libc to provide these functions, but that's not in 
the present specification or implementation.  If anyone is still using ARM 
old-ABI, they aren't in libgcc there either.

It is however safe on Linux targets to do link tests rather than just 
looking at the .s output of the compiler (looking at .s output being what 
gives misleading results when the functions are in libgcc or libc rather 
than built in).

But there is one further complication.  C++ shared libraries are linked 
with -shared-libgcc by default.  The __sync_* functions on ARM and PA are 
in static libgcc only (and it looks like those on SH are always hidden, so 
effectively also static-only).  So you can't actually link a C++ shared 
library that uses these functions.  I consider this a compiler bug; even 
with -shared-libgcc I think the compiler needs to link with the static 
libgcc, after the shared one, so that undefined references to 
static-libgcc-only functions such as these can be resolved.

> To end, just want to remind that this issue is essentially very old, just less
> to the fore now thanks to the fact that x86_64 is so popular: eg, it woul be
> so nice if people targeting i?86 could assume the builtins to be always
> available.

On i486 and later they are available.  As for i686-pc-linux-gnu not 
defaulting to -march=i686 in the compiler (libstdc++ does select 
directories based on the target name as if it did mean -march not -mtune, 
however), perhaps someone could review HJ's patch 
<http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html>?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Hi,

and, first, thanks for the various clarifications.
> Linux targets *don't* necessarily have the __sync_* functions.  For 
> example, they are not available on ColdFire (even with Maxim's TLS patch 
> which I imagine will be updated and reposted in due course now we are in 
> Stage 1), since atomic operations there use a kernel helper in a vDSO.  It 
> would be possible for libc to provide these functions, but that's not in 
> the present specification or implementation.  If anyone is still using ARM 
> old-ABI, they aren't in libgcc there either.
>
> It is however safe on Linux targets to do link tests rather than just 
> looking at the .s output of the compiler (looking at .s output being what 
> gives misleading results when the functions are in libgcc or libc rather 
> than built in).
>   
I'm not sure if we already discussed a bit the following: would it make
sense to change those tests along the lines of GCC_TRY_COMPILE_OR_LINK?
I mean, if gcc_no_link  is yes, then we just do what we currently do, 
we look at the .s output, otherwise we do a test, completely analogous
to the one used already in libgomp, for example. That would be not just
for linux, but for all targets.

Thanks,
Paolo.

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Joseph S. Myers]

On Sat, 2 May 2009, Paolo Carlini wrote:

> I'm not sure if we already discussed a bit the following: would it make
> sense to change those tests along the lines of GCC_TRY_COMPILE_OR_LINK?
> I mean, if gcc_no_link  is yes, then we just do what we currently do, 
> we look at the .s output, otherwise we do a test, completely analogous
> to the one used already in libgomp, for example. That would be not just
> for linux, but for all targets.

Subject to fixing the bug I think is present with static-only libgcc 
functions and C++ shared libraries (so that being able to link an 
executable with the functions means it is also possible to link libstdc++ 
and have the symbols resolved in that link), it would make sense to test 
linking if possible, failing that the .s file.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Hi,
>> I'm not sure if we already discussed a bit the following: would it make
>> sense to change those tests along the lines of GCC_TRY_COMPILE_OR_LINK?
>> I mean, if gcc_no_link  is yes, then we just do what we currently do, 
>> we look at the .s output, otherwise we do a test, completely analogous
>> to the one used already in libgomp, for example. That would be not just
>> for linux, but for all targets.
>>     
> Subject to fixing the bug I think is present with static-only libgcc 
> functions and C++ shared libraries (so that being able to link an 
> executable with the functions means it is also possible to link libstdc++ 
> and have the symbols resolved in that link), it would make sense to test 
> linking if possible, failing that the .s file.
>   
Ok, thanks. Then, I think I'll implement this, for now. Seems in any
case conservative to have a link type test identical to the one used in
libgomp and libgfortran and a fall back to the .s file (as currently used).

Paolo.

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

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

Paolo Carlini wrote:
> Ok, thanks. Then, I think I'll implement this, for now. Seems in any
> case conservative to have a link type test identical to the one used in
> libgomp and libgfortran and a fall back to the .s file (as currently used).
>   
I committed the below to mainline. Assuming no issues are noticed with
it, I mean to apply it to 4_4-branch too in a few days.

Paolo.

/////////////////////

[-- Attachment #2: CL_configure --]
[-- Type: text/plain, Size: 163 bytes --]

2009-05-03  Paolo Carlini  <paolo.carlini@oracle.com>

	* acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): Do link tests when
	possible.
	* configure: Regenerate.

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

Index: acinclude.m4
===================================================================
--- acinclude.m4	(revision 147071)
+++ acinclude.m4	(working copy)
@@ -2429,8 +2429,7 @@
 dnl that are used should be checked.
 dnl
 dnl Note:
-dnl libgomp and libgfortran do this with a link test, instead of an asm test.
-dnl see: CHECK_SYNC_FETCH_AND_ADD
+dnl libgomp and libgfortran use a link test, see CHECK_SYNC_FETCH_AND_ADD.
 dnl
 dnl Defines:
 dnl  _GLIBCXX_ATOMIC_BUILTINS_1 
@@ -2442,12 +2441,110 @@
   AC_LANG_SAVE
   AC_LANG_CPLUSPLUS
   old_CXXFLAGS="$CXXFLAGS"
-  
+
+  # Do link tests if possible, instead asm tests.
+  if test x$gcc_no_link != xyes; then  
+
+  # Can do link tests.
+
+  CXXFLAGS="$CXXFLAGS -fno-exceptions"
+
+  AC_MSG_CHECKING([for atomic builtins for bool])
+  AC_CACHE_VAL(glibcxx_cv_atomic_bool, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef bool atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_bool=yes],
+      [glibcxx_cv_atomic_bool=no])
+  ])    
+  if test $glibcxx_cv_atomic_bool = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
+      [Define if builtin atomic operations for bool are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_bool)
+
+  AC_MSG_CHECKING([for atomic builtins for short])
+  AC_CACHE_VAL(glibcxx_cv_atomic_short, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef short atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_short=yes],
+      [glibcxx_cv_atomic_short=no])
+  ])    
+  if test $glibcxx_cv_atomic_short = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
+      [Define if builtin atomic operations for short are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_short)
+
+  AC_MSG_CHECKING([for atomic builtins for int])
+  AC_CACHE_VAL(glibcxx_cv_atomic_int, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef int atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_int=yes],
+      [glibcxx_cv_atomic_int=no])
+  ])    
+  if test $glibcxx_cv_atomic_int = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
+      [Define if builtin atomic operations for int are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_int)
+
+  AC_MSG_CHECKING([for atomic builtins for long long])
+  AC_CACHE_VAL(glibcxx_cv_atomic_long_long, [
+    AC_TRY_LINK(
+      [ ],
+      [typedef long long atomic_type;
+       atomic_type c1;
+       atomic_type c2;
+       const atomic_type c3(0);
+       __sync_fetch_and_add(&c1, c2);
+       __sync_val_compare_and_swap(&c1, c3, c2);
+       __sync_lock_test_and_set(&c1, c3);
+       __sync_lock_release(&c1);
+       __sync_synchronize();],
+      [glibcxx_cv_atomic_long_long=yes],
+      [glibcxx_cv_atomic_long_long=no])
+  ])    
+  if test $glibcxx_cv_atomic_long_long = yes; then
+    AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
+      [Define if builtin atomic operations for long long are supported on this host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_long_long)
+
+  else
+
+  # Do asm tests.
+
   # Compile unoptimized.
   CXXFLAGS='-O0 -S'
 
-  # Fake what AC_TRY_COMPILE does, without linking as this is
-  # unnecessary for a builtins test.
+  # Fake what AC_TRY_COMPILE does.
 
     cat > conftest.$ac_ext << EOF
 [#]line __oline__ "configure"
@@ -2469,14 +2566,14 @@
     AC_MSG_CHECKING([for atomic builtins for bool])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinsb=no
+        glibcxx_cv_atomic_bool=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
       [Define if builtin atomic operations for bool are supported on this host.])
-        enable_atomic_builtinsb=yes
+        glibcxx_cv_atomic_bool=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinsb)
+    AC_MSG_RESULT($glibcxx_cv_atomic_bool)
     rm -f conftest*
 
     cat > conftest.$ac_ext << EOF
@@ -2499,14 +2596,14 @@
     AC_MSG_CHECKING([for atomic builtins for short])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinss=no
+        glibcxx_cv_atomic_short=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
       [Define if builtin atomic operations for short are supported on this host.])
-        enable_atomic_builtinss=yes
+        glibcxx_cv_atomic_short=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinss)
+    AC_MSG_RESULT($glibcxx_cv_atomic_short)
     rm -f conftest*
 
     cat > conftest.$ac_ext << EOF
@@ -2530,14 +2627,14 @@
     AC_MSG_CHECKING([for atomic builtins for int])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinsi=no
+        glibcxx_cv_atomic_int=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
         [Define if builtin atomic operations for int are supported on this host.])
-        enable_atomic_builtinsi=yes
+        glibcxx_cv_atomic_int=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinsi)
+    AC_MSG_RESULT($glibcxx_cv_atomic_int)
     rm -f conftest*
 
     cat > conftest.$ac_ext << EOF
@@ -2560,22 +2657,23 @@
     AC_MSG_CHECKING([for atomic builtins for long long])
     if AC_TRY_EVAL(ac_compile); then
       if grep __sync_ conftest.s >/dev/null 2>&1 ; then
-        enable_atomic_builtinsll=no
+        glibcxx_cv_atomic_long_long=no
       else
       AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
       [Define if builtin atomic operations for long long are supported on this host.])
-        enable_atomic_builtinsll=yes
+        glibcxx_cv_atomic_long_long=yes
       fi
     fi
-    AC_MSG_RESULT($enable_atomic_builtinsll)
+    AC_MSG_RESULT($glibcxx_cv_atomic_long_long)
     rm -f conftest*
 
+  fi
 
   CXXFLAGS="$old_CXXFLAGS"
   AC_LANG_RESTORE
 
   # Set atomicity_dir to builtins if either of above tests pass.
-  if test $enable_atomic_builtinsi = yes || test $enable_atomic_builtinsb = yes ; then
+  if test $glibcxx_cv_atomic_int = yes || test $glibcxx_cv_atomic_bool = yes ; then
     atomicity_dir=cpu/generic/atomicity_builtins
   fi
 

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Mark Mitchell]

Paolo Carlini wrote:

>> Subject to fixing the bug I think is present with static-only libgcc 
>> functions and C++ shared libraries (so that being able to link an 
>> executable with the functions means it is also possible to link libstdc++ 
>> and have the symbols resolved in that link), it would make sense to test 
>> linking if possible, failing that the .s file.
>>   
> Ok, thanks. Then, I think I'll implement this, for now. Seems in any
> case conservative to have a link type test identical to the one used in
> libgomp and libgfortran and a fall back to the .s file (as currently used).

I think this is a reasonable strategy.  It's critical to avoid run-time
tests, as they don't work in cross configurations, but link-time tests
are not inherently problematic in the same way.  I think that link-time
tests are a reasonable approach.

If I recall correctly, the strongest objection to link-time tests comes
from people who do a "one-tree" build of an entire cross-toolchain.  I
think that if you can't link a C program (including using functions from
the C library) by the time you get to the point of building libstdc++,
that's a bug in the one-tree build procedure, but that's probably not a
fight worth having.

There's a secondary issue with link-time tests because you then up
determining things about the C library that may not be true if you use a
different C library, or a different version of the same C library, or
whatever.  I think some of those concerns are reasonable, but I think
the right way to deal with them is probably explicit configure options
for the benefit of people who want to make the C++ run-time use (or not
use) some feature of the C library that is different from what would be
determined by the link-time probe.  So, I think that this is an
orthogonal issue to the question of how we should probe.

FWIW,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Matthias Klose]

Paolo Carlini schrieb:
> Paolo Carlini wrote:
>> Ok, thanks. Then, I think I'll implement this, for now. Seems in any
>> case conservative to have a link type test identical to the one used in
>> libgomp and libgfortran and a fall back to the .s file (as currently used).
>>   
> I committed the below to mainline. Assuming no issues are noticed with
> it, I mean to apply it to 4_4-branch too in a few days.

with this patch applied to the 4.4 branch, the tests now succeed as expected on
the 4_4-branch on {armeabi,hppa,sparc}-linux.

thanks, Matthias

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Matthias Klose wrote:
> Paolo Carlini schrieb:
>   
>> Paolo Carlini wrote:
>>     
>>> Ok, thanks. Then, I think I'll implement this, for now. Seems in any
>>> case conservative to have a link type test identical to the one used in
>>> libgomp and libgfortran and a fall back to the .s file (as currently used).
>>>   
>>>       
>> I committed the below to mainline. Assuming no issues are noticed with
>> it, I mean to apply it to 4_4-branch too in a few days.
>>     
> with this patch applied to the 4.4 branch, the tests now succeed as expected on
> the 4_4-branch on {armeabi,hppa,sparc}-linux.
>   
Good. I have now backported the patch to 4_4-branch too. Please double
check that the regression tests are also fine, thanks in advance.

Paolo.

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Matthias Klose]

Paolo Carlini schrieb:
> Matthias Klose wrote:
>> Paolo Carlini schrieb:
>>   
>>> Paolo Carlini wrote:
>>>     
>>>> Ok, thanks. Then, I think I'll implement this, for now. Seems in any
>>>> case conservative to have a link type test identical to the one used in
>>>> libgomp and libgfortran and a fall back to the .s file (as currently used).
>>>>   
>>>>       
>>> I committed the below to mainline. Assuming no issues are noticed with
>>> it, I mean to apply it to 4_4-branch too in a few days.
>>>     
>> with this patch applied to the 4.4 branch, the tests now succeed as expected on
>> the 4_4-branch on {armeabi,hppa,sparc}-linux.
>>   
> Good. I have now backported the patch to 4_4-branch too. Please double
> check that the regression tests are also fine, thanks in advance.

Jakub pointed out on irc that sparc-linux (32bit, v8) doesn't have the atomic
support functions. Building a 32bit v9 compiler as part of a biarch build is
currently not supported (64bit and v9 are tightly coupled).

No regressions on hppa-linux.

On arm-linux-gnueabi there are regressions of the form

/usr/bin/ld: ./atomic-1.exe: hidden symbol `__sync_val_compare_and_swap_4' in
/home/doko/gcc/4.4/gcc-4.4-4.4.0/build/gcc/libgcc.a(linux-atomic.o) is
referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output

in the libgomp, libstdc++ and g++ testsuites. Linking the shared libstdc++ with
both -lgcc_s and -lgcc does fix these (testsuites currently running), however
I'm not sure how to do this properly, as libtool removes any `-lgcc' argument.

  Matthias

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Matthias Klose wrote:
> On arm-linux-gnueabi there are regressions of the form
>
> /usr/bin/ld: ./atomic-1.exe: hidden symbol `__sync_val_compare_and_swap_4' in
> /home/doko/gcc/4.4/gcc-4.4-4.4.0/build/gcc/libgcc.a(linux-atomic.o) is
> referenced by DSO
> /usr/bin/ld: final link failed: Nonrepresentable section on output
>
> in the libgomp, libstdc++ and g++ testsuites. Linking the shared libstdc++ with
> both -lgcc_s and -lgcc does fix these (testsuites currently running), however
> I'm not sure how to do this properly, as libtool removes any `-lgcc' argument.
>   
I see, looks like the problem warned about by Joseph is biting us. For
the time being I reverted the patch both from mainline and the branch.
Please make sure it gets fixed properly and then let's reconsider the
libstdc++ patch, for mainline at least.

Thanks,
Paolo.

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Ralf Wildenhues]

* Matthias Klose wrote on Wed, May 06, 2009 at 09:44:07AM CEST:
> On arm-linux-gnueabi there are regressions of the form
> 
> /usr/bin/ld: ./atomic-1.exe: hidden symbol `__sync_val_compare_and_swap_4' in
> /home/doko/gcc/4.4/gcc-4.4-4.4.0/build/gcc/libgcc.a(linux-atomic.o) is
> referenced by DSO
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> 
> in the libgomp, libstdc++ and g++ testsuites. Linking the shared libstdc++ with
> both -lgcc_s and -lgcc does fix these (testsuites currently running), however
> I'm not sure how to do this properly, as libtool removes any `-lgcc' argument.

In order to be able to anayze this (and either confirm or refute a
possible libtool bug), I would like to see the './libtool --mode=link'
command that fails, plus all of its output with --debug added as first
argument; further the output of
  ./libtool --tag=TAG --config

with TAG replaced by the tag used for the link.

Thanks,
Ralf

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Matthias Klose]

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

Ralf Wildenhues schrieb:
> * Matthias Klose wrote on Wed, May 06, 2009 at 09:44:07AM CEST:
>> On arm-linux-gnueabi there are regressions of the form
>>
>> /usr/bin/ld: ./atomic-1.exe: hidden symbol `__sync_val_compare_and_swap_4' in
>> /home/doko/gcc/4.4/gcc-4.4-4.4.0/build/gcc/libgcc.a(linux-atomic.o) is
>> referenced by DSO
>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>>
>> in the libgomp, libstdc++ and g++ testsuites. Linking the shared libstdc++ with
>> both -lgcc_s and -lgcc does fix these (testsuites currently running), however
>> I'm not sure how to do this properly, as libtool removes any `-lgcc' argument.
> 
> In order to be able to anayze this (and either confirm or refute a
> possible libtool bug), I would like to see the './libtool --mode=link'
> command that fails, plus all of its output with --debug added as first
> argument; further the output of
>   ./libtool --tag=TAG --config
> 
> with TAG replaced by the tag used for the link.

log attached. the link command doesn't fail, but it differs which files are
included from libgcc.a. -lm -lgcc_s -lgcc gets reordered to -lm -lgcc -lc
-lgcc_s, which does resolve the __aeabi_* symbols as well. just appending -lgcc
to libtool's postdeps only resolves the __sync_* symbols (only found in libgcc.a).

  Matthias

[-- Attachment #2: log.gz --]
[-- Type: application/x-gzip, Size: 34363 bytes --]

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Hi again
> Subject to fixing the bug I think is present with static-only libgcc 
> functions and C++ shared libraries (so that being able to link an 
> executable with the functions means it is also possible to link libstdc++ 
> and have the symbols resolved in that link), it would make sense to test 
> linking if possible, failing that the .s file.
>   
As you may have noticed, the exception propagation support issue
(PR40133) is still open exactly because we are blocked by the issue
which you pointed out here (now PR40134). In the meanwhile PR 40178 has
been also filed, which would be also fixed by the same patch fixing PR40133.

Could you provide some further guidance on PR40134, that this the
static-only libgcc functions issue? Or maybe indicate a maintainer for
the relavant part of the compiler?

Thanks a lot in advance,
Paolo.