From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21007 invoked by alias); 3 Jan 2006 22:09:39 -0000 Received: (qmail 20990 invoked by uid 22791); 3 Jan 2006 22:09:38 -0000 X-Spam-Check-By: sourceware.org Received: from dsl027-180-168.sfo1.dsl.speakeasy.net (HELO sunset.davemloft.net) (216.27.180.168) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 03 Jan 2006 22:09:37 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=localhost ident=davem) by sunset.davemloft.net with esmtp (Exim 4.60) (envelope-from ) id 1EtuLW-0006II-6N; Tue, 03 Jan 2006 14:09:34 -0800 Date: Tue, 03 Jan 2006 22:09:00 -0000 Message-Id: <20060103.140932.126869388.davem@davemloft.net> To: jakub@redhat.com Cc: drepper@redhat.com, libc-hacker@sources.redhat.com Subject: Re: [PATCH] NPTL SPARC pre-v9 support From: "David S. Miller" In-Reply-To: <20060103213611.GN4625@sunsite.mff.cuni.cz> References: <20060103213611.GN4625@sunsite.mff.cuni.cz> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00013.txt.bz2 From: Jakub Jelinek Date: Tue, 3 Jan 2006 22:36:11 +0100 > The following patch (almost) implements what has been outlined in > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161736 > The major changes from that outline are that it should (am still verifying > that) cause no changes whatsoever for sparcv9 or sparc64 built glibc, > sparc built glibc's shared libraries expected to work properly just on > pre-v9 CPUs and sparc built .a libraries (and therefore statically linked > 32-bit binaries too) be able to cope with both, by using CAS on 64-bit > CPUs and various hacks on 32-bit CPUs. > > So far I have done sparc-linux NPTL build and make check (worked fine), > am sparcv9-linux NPTL build and make check, plus verified that stripped > libc.so/libpthread.so are identical on sparcv9-linux without and with this > patch. > > As written in the outline, on pre-v9 CPUs it uses the ldstub lock pool > indexed by hashed address for most of the atomic stuff, ldstub lock > in the upper 8 bits of the 32-bit value for locks (where only 0, 1 and 2 > are valid values (but anything < 16M is ok) and for process shared > barriers as well as all semaphores uses a ldstub lock in the padding > between the (smaller) internal structure and bigger exported type. Thanks for getting around to this work Jakub. At a minimum I'll do build/test runs on sparc{,v9,v9b,64,64b}-linux.