This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Implementing C++1x and C1x atomics
On Fri, 14 Aug 2009, Lawrence Crowl wrote:
> So, if -march=D should not imply inlining of the atomic operations,
> we need another option that does. That other option in turn
> must require the dynamic library use compatible implementations.
> (I'd really like to see errors caught by the loader.)
The loader doesn't catch you using a processor extension that adds new
call-preserved registers when setjmp/longjmp haven't been updated to
handle those registers (one existing case that I think unavoidably does
require a new libc to use a feature of a new architecture). Fortunately,
most people producing ABIs for such processor extensions realise it's best
to make the new registers call-clobbered so that setjmp/longjmp and
unwinding don't need to handle them.
> > /* in stdc-predef.h (or stdatomic.h if you don't like stdc-predef.h) */
> > #ifdef __arch_D__
> > #pragma GCC atomic_8byte_ok_to_inline
> > #endif
>
> I must say the header approach really worries me. The problem is
> that the library that you compile under may not be the library that
> you execute under. I shudder to think what shipping preprocessor
> output from one system to another will do.
It is required when using glibc that:
(A) Code compiled against headers from libc version X must be run with
libc version X or later.
(B) Code compiled against headers from libc version X must be linked into
an executable or shared library against a binary of libc version X
(exactly). .o and .a files are not necessarily compatible from one
version to the next, since compiling against headers from version X means
the object needs the versions of functions that are provided by libc
version X, but the symbol references are only bound to particular symbol
versions at the point at which you link with libc.so. (It's been a long
time since there was major breakage of this sort affecting lots of static
libraries - I think maybe the 2.2-to-2.3 transition - but the principle
remains that symbol versioning does not assure compatibility for .o and .a
files, only for executables and shared libraries.)
As long as you follow (A) and each libc version knows about all the atomic
instruction cases the previous one know about, having libc declare to the
compiler when it's safe to inline atomic operations (with the default in
the absence of such a declaration from libc being only to inline
operations if they are present on all subarchitectures and there is no
lock-based libc implementation with which to be incompatible) should work
fine.
--
Joseph S. Myers
joseph@codesourcery.com