On 8/14/09, Joseph S. Myers <jos...@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
