On Mon, 17 Aug 2009, Lawrence Crowl wrote: > > Ways for the kernel or dynamic linker to detect such > > incompatibilities may be useful, but would apply to this issue > > in general, not specifically to atomic operations. > > The difference with the atomics is that if an application uses the > D instructions, we also need the dynamic library to also use the > D instructions (on a D or later processor). How do we ensure that?
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.) > If we cannot, then I am concerned that we would be able to inline > no atomic operations without dropping support for the 80386 as > a subset of the later processors. The same situation applies to > other processor families. 80386 support is already dropped (effectively) in glibc, and has been for quite some time; you have to use -march=i486 or later to build glibc for IA32, or it will fail to link with missing atomic operations. -- Joseph S. Myers jos...@codesourcery.com
