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 Wed, 19 Aug 2009, Lawrence Crowl wrote:

> I am quoting from several different messages.
> On 8/17/09, Joseph S. Myers <> wrote:
> > (A) Code compiled against headers from libc version X must be run
> > with libc version X or later.
> What is the symptom of failing to meet this constraint?

Depending on what features the code uses and when you pass it to the 
static linker, there may be errors from the static linker or the dynamic 
linker, misbehavior at runtime (e.g. if you pass a new flag to a function 
that doesn't know about that flag in the old libc) or no symptoms.

> > > 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?
> >
> > You get SIGILL when the atomic instruction that is present on D
> > but not E is executed.  That a program built for one processor
> > (D) but executed on another (E), whose features are not a superset
> > of those of D, will get SIGILL, or execute incorrectly if E does
> > something else on encountering that instruction, is not in any way
> > specific to atomic instructions; it applies to every architecture
> > with more than one supported variant.
> There is a very similar scenario, that is problematic.  Suppose that
> the application A uses only instructions from E.  It will execute every
> instruction correctly, but because the application uses a non-locking
> implementation and the library uses a locking implementation, there
> will be synchronization failure.

If you built with -march=E, the library should not have told the compiler 
that it could inline the atomic operations.

> > I have suggested that the library inform the compiler, via its headers
> > (whatever the details - pragmas, macros, etc. - and whether or not
> > the header in question is implicitly preincluded) of whether the
> > library will be using these instructions, with the compiler making
> > safe assumptions if the library does not give it this information.
> > (The information passed from the library to the compiler would be an
> > assertion that that library version, and all later versions, when
> > used on a D or later processor, will always use the D instructions
> > or later instructions that safely interoperate with them.)
> Is this header provided with the compiler or the operating system?
> In part, I am concerned about gcc on non-Linux systems.

The header would be provided by the provider of the library which includes 
any out-of-line atomic functions that may be lock-based, which we had 
previously concluded would be libc (rather than libgcc) on Linux systems.  
(We also concluded that the set of such functions and their names would be 
considered part of the platform ABI for that system.)  If the OS provides 
a header that is not suitable for GCC then it may need fixing with 

This works best for C++ if we do not try to support the C++ atomics (or at 
least those that might need lock-based implementations) in the absence of 
libc support for the C atomics; certainly it seems lock-based 
implementations in libstdc++ must be avoided to avoid conflict with such 
implementations in libc.

Joseph S. Myers

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