Bug 40133 - exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-linux
Summary: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.4.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 40178 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-05-13 16:53 UTC by Debian GCC Maintainers
Modified: 2009-12-14 00:19 UTC (History)
4 users (show)

See Also:
Host:
Target: arm-linux-gnueabi hppa-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-05-22 13:36:43


Attachments
put ARM EABI atomic builtins in both shared and static libgcc (278 bytes, patch)
2009-05-22 10:07 UTC, Mikael Pettersson
Details | Diff
always pass -lgcc to linker (610 bytes, patch)
2009-05-22 19:18 UTC, Mikael Pettersson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Debian GCC Maintainers 2009-05-13 16:53:44 UTC
Tracking http://gcc.gnu.org/ml/gcc/2009-05/msg00035.html as a bug report.

Paolo checked in a patch in rev 147123 on the gcc-4_4-branch to do link tests for the atomic builtins, which works ok on hppa, but fails for arm.
Comment 1 Debian GCC Maintainers 2009-05-13 17:07:07 UTC
the arm failure is PR40134 now.

Comment 2 Paolo Carlini 2009-05-13 18:42:16 UTC
To be clear, due to PR40134, the patch mentioned has been reverted for now.
Comment 3 Paolo Carlini 2009-05-13 18:42:37 UTC
To be clear, due to PR40134, the patch mentioned has been reverted for now.
Comment 4 Andrew Pinski 2009-05-17 18:42:13 UTC
*** Bug 40178 has been marked as a duplicate of this bug. ***
Comment 5 Mikael Pettersson 2009-05-22 10:07:44 UTC
Created attachment 17900 [details]
put ARM EABI atomic builtins in both shared and static libgcc

I reviewed the original ARM EABI atomic builtins code submission, and there was no indication that making this code static-libgcc only was anything but an accident. The attached patch makes the code available in both the shared and static libgcc. With this patch and r147123 reapplied to my gcc-4.4 tree the libstdc++ build now finds the atomic builtins as it should:

checking for atomic builtins for bool... yes
checking for atomic builtins for short... yes
checking for atomic builtins for int... yes
checking for atomic builtins for long long... no
Comment 6 joseph@codesourcery.com 2009-05-22 10:22:18 UTC
Subject: Re:  exception propagation support not enabled
 in libstdc++ 4.4 on {armeabi,hppa}-linux

On Fri, 22 May 2009, mikpe at it dot uu dot se wrote:

> Created an attachment (id=17900)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17900&action=view)
> put ARM EABI atomic builtins in both shared and static libgcc
> 
> I reviewed the original ARM EABI atomic builtins code submission, and there was
> no indication that making this code static-libgcc only was anything but an
> accident. The attached patch makes the code available in both the shared and
> static libgcc. With this patch and r147123 reapplied to my gcc-4.4 tree the
> libstdc++ build now finds the atomic builtins as it should:

This patch is obviously wrong - if you put things in shared libgcc you 
also need to assign symbol versions to them based on the version in which 
they were actually added.  I'm pretty sure making them static-only was 
deliberate (following SH which defines all the functions as hidden, which 
has the same effect as making them static-only, for example); the overhead 
of PLT calls is going to be significant for such small functions.

Since the patch doesn't stop the functions being hidden in linux-atomic.c, 
I doubt it actually works (the question is not configure finding them, but 
whether C++ shared libraries that use them link OK with -shared-libgcc).  
The only use of having these functions in shared libgcc while still hidden 
is if other functions in libgcc use them.

Now, I see that SH has libgcc/config/sh/t-linux which makes libgcc_s.so a 
linker script rather than a symlink.  It's possible this could help for 
ARM, but on the whole I think it would be better for -shared-libgcc to use 
the static libgcc as needed after the shared one.

Comment 7 Mikael Pettersson 2009-05-22 11:16:26 UTC
(In reply to comment #6)
> This patch is obviously wrong - if you put things in shared libgcc you 
> also need to assign symbol versions to them based on the version in which 
> they were actually added.

Yeah, I realized that shortly after posting the patch. My bad.

>  I'm pretty sure making them static-only was 
> deliberate (following SH which defines all the functions as hidden, which 
> has the same effect as making them static-only, for example); the overhead 
> of PLT calls is going to be significant for such small functions.

Perhaps that was the motivation, but it's being applied very inconsistently. The ARM EABI backend puts lots of tiny functions, smaller than the __sync__ ones, in both the shared and static libgcc.

> ..., but on the whole I think it would be better for -shared-libgcc to use 
> the static libgcc as needed after the shared one.

Like a tweak to LINK_SPEC? I'll see if I can cook something up.
Comment 8 Mikael Pettersson 2009-05-22 19:18:45 UTC
Created attachment 17902 [details]
always pass -lgcc to linker

The link error reported by Matthias Klose is caused by the following:
1. g++ links shared libraries with -shared-libgcc, which apparently is important      whenever exceptions are possible.
2. -shared-libgcc by definition excludes the static libgcc from the link command.
3. Since the __sync__ procedures are only present in the static libgcc, it follows that they cannot be used by -shared-libgcc objects like libstdc++.so.

One way around this is to redefine -shared-libgcc to actually link against the static libgcc, contrary to its intention. Both mingw32 and cygwin do this, so it's not unheard of. The attached patch updates ARM EABI to do just that. Passes a bootstrap and light testing here.

However, I would strongly prefer to just move the __sync__ procedures to the shared libgcc (with symbol versions of course).
Comment 9 Paolo Carlini 2009-05-22 20:30:39 UTC
Two general comments: 1- Patches should be in any case posted to the gcc-patches mailing list; 2- I got previous feedbacks from Joseph as meaning that the issue is general, not restricted to the arm config; 3- Being a compiler issue I'm not even sure it should be discussed here - this PR is about the C++ library - probably PR40134 is the proper place.
Comment 10 Matthias Klose 2009-12-13 23:45:26 UTC
Subject: Bug 40133

Author: doko
Date: Sun Dec 13 23:45:12 2009
New Revision: 155200

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155200
Log:
2009-12-11  Paolo Carlini  <paolo.carlini@oracle.com>
            Matthias Klose  <doko@ubuntu.com>

        PR libstdc++/40133
        * acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): On *-*-linux*,
        *-*-uclinux*, *-*-kfreebsd*-gnu | *-*-gnu* targets do link tests when
        possible.
        * configure: Regenerate.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/acinclude.m4
    trunk/libstdc++-v3/configure

Comment 11 Debian GCC Maintainers 2009-12-14 00:19:57 UTC
fixed on the trunk