This is the mail archive of the libc-alpha@sourceware.org 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: Correct robust mutex / PI futex kernel assumptions (bug 9894)


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.


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