Correct robust mutex / PI futex kernel assumptions (bug 9894)
David Miller
davem@davemloft.net
Tue Mar 25 04:30:00 GMT 2014
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Tue, 25 Mar 2014 00:21:28 +0000
> On Mon, 24 Mar 2014, David Miller wrote:
>
>> From: "Joseph S. Myers" <joseph@codesourcery.com>
>> Date: Mon, 24 Mar 2014 21:42:08 +0000
>>
>> > On SPARC, 32-bit kernels don't support futex_atomic_cmpxchg_inatomic.
>> > I don't know if there's a more fine-grained approach than the one
>> > taken here, not assuming the features to be present for 32-bit
>> > userspace since we don't know if it might run on a 32-bit kernel.
>>
>> Just like with low level locks, if we're building for 32-bit plus
>> V9/V8plus, we can assume the full locking primitives are available.
>
> The kernel's asm/futex.h does
>
> #if defined(__sparc__) && defined(__arch64__)
> #include <asm/futex_64.h>
> #else
> #include <asm/futex_32.h>
> #endif
>
> and futex_32.h just uses the asm-generic version, which just returns
> -ENOSYS. Are you saying that if glibc is built for 32-bit plus V9/V8plus,
> then the kernel that glibc binary runs under must have been built with
> defined(__sparc__) && defined(__arch64__) true? If so, what is the
> relevant cpp condition in userspace for "glibc can assume a kernel with
> functional futex_atomic_cmpxchg_inatomic"?
A 32-bit binary compiled for v9 can only execute on 64-bit kernels.
More information about the Libc-alpha
mailing list