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

["Joseph S. Myers" <joseph at codesourcery dot com>]

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