------- Comment #6 from joseph at codesourcery dot com 2009-05-22 10:22 -------
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)
> --> (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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133
