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. -- Joseph S. Myers jos...@codesourcery.com
