This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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  (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 

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]