This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Implementing C++1x and C1x atomics

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]