From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48420 invoked by alias); 25 Oct 2016 16:22:03 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 48338 invoked by uid 89); 25 Oct 2016 16:22:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Riegel, riegel, kosher, sk:__GCC_A X-HELO: mx1.redhat.com Message-ID: <1477412515.7146.118.camel@localhost.localdomain> Subject: Re: Remove sparcv8 support From: Torvald Riegel To: Andreas Larsson Cc: Adhemerval Zanella , GNU C Library , David Miller , "software@gaisler.com" Date: Tue, 25 Oct 2016 16:22:00 -0000 In-Reply-To: <580F6D57.2000309@gaisler.com> References: <48cdf008-b66a-d411-a07a-5a38595978b9@linaro.org> <5809D90E.1090005@gaisler.com> <1477329945.7146.95.camel@localhost.localdomain> <580F6D57.2000309@gaisler.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00432.txt.bz2 On Tue, 2016-10-25 at 16:33 +0200, Andreas Larsson wrote: > On 2016-10-24 19:25, Torvald Riegel wrote: > > On Fri, 2016-10-21 at 10:59 +0200, Andreas Larsson wrote: > >> We are not always using the latest version of GLIBC (the latest step we > >> took was to GLIBC 2.20), so unfortunately we missed this issue. We will > >> look into what the extent of the missing support is. Any pointers are > >> most welcome. > >> > >> Do you have a link to the suggested options on the 2.23 release thread? > >> I dug around a bit in the archives, but did not find it. > >> > >> (As a side note, most of the recent LEON3 and LEON4 chips have CAS > >> instruction support, but pure sparcv8 support is of course the baseline.) > > > > Yes, the lack of CAS is the major problem I am aware of. If the chips > > you mention do support CAS, then a patch that adds support for the > > CAS-based atomic operations in glibc would fix the barrier problem > > (because the generic barrier should just work). The patch would also > > have to add configure bits or whatever would be appropriate so that > > glibc can figure out whether it is supposed to be run on a sparcv8 with > > or without CAS. > > Perhaps not the kosher way to do it (happy to get feedback if some > other method should be used), but changing > sysdeps/sparc/sparc32/pthread_barrier_wait.c to: > > #if defined(__GCC_ATOMIC_INT_LOCK_FREE) && (__GCC_ATOMIC_INT_LOCK_FREE > 1) > #include > #else > #error No support for pthread barriers on pre-v9 sparc. > #endif The sparc-specific barriers should just go away. atomic-machine.h for sparc v8 should ensure that it provides the atomic operations that are needed (and which work on process-shared uses too). I don't have a real preference for when in the build process we should check whether a real CAS is provided by the HW (eg, at configure time or when trying to use atomic operations). I'd suggest to also look at whether you really need the custom spinlock on sparc; the generic ones should be just as good (if not, it would be good to have a comment in the custom files explaining why we need those). Also, is the barrier in sysdeps/sparc/sparc64/pthread_spin_trylock.S at the right position wrt. to the actual acquisiton of the lock? (OTOH, I think we assume TSO anyway, so a misplaced acquire or release MO fence is harmless).