On 8/14/09, Joseph S. Myers <jos...@codesourcery.com> wrote: > 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.)
Yes. > 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. Yuck. > 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? 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. -- Lawrence Crowl
