On 8/19/09, Joseph S. Myers <jos...@codesourcery.com> wrote: > On Wed, 19 Aug 2009, Lawrence Crowl wrote: > > > I am quoting from several different messages. > > > > On 8/17/09, Joseph S. Myers <jos...@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.
Okay. Just to be clear, any lock-based implementation should exist only in the library, never inlined. > 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. Agreed 100%. The intent was that all the C++-specific stuff be implemented in terms of the C-specific stuff, independent of the platform. -- Lawrence Crowl