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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Miller <davem at davemloft dot net>
- 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 15:35:00 +0000
- 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> <20140325 dot 111221 dot 1312938819719077958 dot davem at davemloft dot net>
On Tue, 25 Mar 2014, David Miller wrote:
> 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.
In that case, I'd like to propose the SPARC changes in the patch as-is
(i.e. not assuming these features for 32-bit SPARC).
I *would* like all architectures to move to architecture-specific
kernel-features.h files as used for ex-ports architectures (overriding the
architecture-independent file as needed) - but such a move will be a lot
simpler after the move to 2.6.32 minimum kernel version and some of the
consequent cleanups, and that depends on this patch (and the previous
MicroBlaze one pending review) to avoid possibly breaking things for some
architectures.
--
Joseph S. Myers
joseph@codesourcery.com