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 Wed, 19 Aug 2009, Lawrence Crowl wrote:
> I am quoting from several different messages.
>
> On 8/17/09, Joseph S. Myers <joseph@codesourcery.com> 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
fixincludes.
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
joseph@codesourcery.com