This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Correct robust mutex / PI futex kernel assumptions (bug 9894)
- From: David Miller <davem at davemloft dot net>
- To: joseph at codesourcery dot com
- Cc: libc-alpha at sourceware dot org, schwab at linux-m68k dot org, david dot holsgrove at xilinx dot com, aurel32 at debian dot org
- Date: Tue, 25 Mar 2014 11:12:21 -0400 (EDT)
- Subject: Re: Correct robust mutex / PI futex kernel assumptions (bug 9894)
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1403250019020 dot 1129 at digraph dot polyomino dot org dot uk> <20140325 dot 003012 dot 76042767860370362 dot davem at davemloft dot net> <Pine dot LNX dot 4 dot 64 dot 1403251217091 dot 12472 at digraph dot polyomino dot org dot uk>
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Tue, 25 Mar 2014 12:19:12 +0000
> On Tue, 25 Mar 2014, David Miller wrote:
>
>> > 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.
>
> Thanks for the explanation. What's the right preprocessor conditional for
> requiring a 64-bit kernel (to replace the "defined __arch64__" in my
> patch)?
There isn't. You really have to base it upon the config triplet, by
placing the header file in question under a sparc32/v9 subdirectory.
You could include atomic.h and do tests on __sparc32_atomic_do_lock like
lowlevellock.h does, but that's really ugly.