Re: Implementing C++1x and C1x atomics

[Lawrence Crowl <crowl at google dot com>]

On 8/14/09, Joseph S. Myers <joseph@codesourcery.com> wrote:
> 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.

So, suppose I compile my program A, using libc version X, on
a processor of type D, which permits me to inline the atomic
operations.  Then suppose that I execute A on a processor of type E,
which has libc version X, but which supports fewer atomic operations
and thus requires a locking implementation.  I have met all the
versioning requirements.  What happens?

-- 
Lawrence Crowl