On Fri, 14 Aug 2009, Lawrence Crowl wrote: > 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?
(I will suppose that by "compile ... on a processor of type D" you mean compile with the compiler told to target D (explicitly with -march=D, or implicitly with -march=native, or with a compiler configured --with-arch=D), since the processor of the target is in general independent of that of the host.) 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. 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. -- Joseph S. Myers jos...@codesourcery.com
