From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5672 invoked by alias); 26 Oct 2016 18:03:06 -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 5662 invoked by uid 89); 26 Oct 2016 18:03:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=BAYES_40,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=effortlessly, Meaning, seconded, standpoint X-HELO: mail-ua0-f176.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=J8S9tcGVIDe58v+v8raUmO15Qb0lJP9ut9jje9VD1cQ=; b=C9oFqWtM6LrpI+Z1LRkazX21qaf8EDBuwa1MRszOEvniUgrTJIH2syDm9Q5sf4FPYJ XdvmJXwnf6RIKbzzg/gvJhNZBxiLirwDtb+ng+gh2h4Z4q/GelcbyDtX1JQZmYT59nJy 5Jx1nZqm/ne/W0e+abAZDvhWwlaSqCnyFXOyLWQVt7lkFYollqMyqkz1cMwRUcOH8vDY p45hwWnk/KmmMTgOuljMvqg3bZ7jfUO/BJ2lpT/M1BhZaDDmnsHKoEKujB/Iz2E6hR2h vPulR0BG26KB4pYK8CiJmcvY4NTnLe5Y4zpXH2NG6/KkgPK5NerflnKWSqc6CH8GvNO1 1q/A== X-Gm-Message-State: ABUngvdSoaDp6QjZCuTKxG9tZsd2jH1NxA8ZBFOpsIgKoZD2Ipdahewkoxn8Evv20YSL+xx7 X-Received: by 10.159.37.235 with SMTP id 98mr319438uaf.115.1477504973513; Wed, 26 Oct 2016 11:02:53 -0700 (PDT) Subject: Re: Remove sparcv8 support To: Andreas Larsson References: <48cdf008-b66a-d411-a07a-5a38595978b9@linaro.org> <5809D90E.1090005@gaisler.com> <1477329945.7146.95.camel@localhost.localdomain> <8224de36-8a30-980c-697b-8e4cae481184@linaro.org> <580F6D5E.6050600@gaisler.com> <5810C1A3.9030504@gaisler.com> Cc: Torvald Riegel , GNU C Library , David Miller , "software@gaisler.com" From: Adhemerval Zanella Message-ID: <10b5e6a5-835d-8dc4-09c6-fc632e0736be@linaro.org> Date: Wed, 26 Oct 2016 18:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <5810C1A3.9030504@gaisler.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00470.txt.bz2 On 26/10/2016 12:45, Andreas Larsson wrote: > On 2016-10-25 16:44, Adhemerval Zanella wrote: >> >> >>> On 25 Oct 2016, at 12:34, Andreas Larsson wrote: >>> >>>> On 2016-10-24 19:42, Adhemerval Zanella wrote: >>>> >>>> >>>>> On 24/10/2016 15:25, Torvald Riegel wrote: >>>>>> On Fri, 2016-10-21 at 10:59 +0200, Andreas Larsson wrote: >>>>>>> On 2016-10-20 21:47, Adhemerval Zanella wrote: >>>>>>> The sparcv8 build is broken since GLIBC 2.23 due the new pthread >>>>>>> barrier implementation [1] and since then there is no thread or >>>>>>> interest on fixing it (Torvald has suggested some options on >>>>>>> 2.23 release thread). It won't help with both new pthread rdlock >>>>>>> and cond implementation, although I would expect that it relies >>>>>>> on same atomic primitive that was not present for pthread barrier. >>>>>>> >>>>>>> AFAIK, recent commercial sparc chips from Oracle all supports >>>>>>> sparcv9. The only somewhat recent sparc chip with just sparcv8 >>>>>>> support is LEON4, which I really doubt it cares for glibc support. >>>>>> >>>>>> Hi! >>>>>> >>>>>> We do care about GLIBC support for many different LEON3 and LEON4 >>>>>> systems. GLIBC support for sparcv8 is important for us and it is >>>>>> important for our customers. Both LEON3 and LEON4 are continuously used >>>>>> in new hardware designs. >>>>> >>>>> If you do care about it, it would be nice if you could (help) maintain >>>>> sparcv8 (e.g., regularly testing most recent glibc on sparcv8, at the >>>>> very least early during the freeze of each release). This ensures that >>>>> you won't get surprises such as this one, when nobody else is spending >>>>> resources on it. >>>>> >>>>>> 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. >>>>> >>>>> What about stopping support for plain sparcv8, and keeping to support >>>>> sparcv8+CAS provided that we have a (group of) maintainer(s) for the >>>>> latter that can tend to the minimal responsibilities of an arch >>>>> maintainer and has the time to do that? >>>> >>>> At least the build for sparcv9-linux-gnu with -mcpu=leon3 finishes, >>>> although I am not sure if it correctly runs on leon processors. >>>> And I seconded Tovarld's suggestion about stop maintaining plain >>>> sparcv8 and set sparcv8+CAS as the base supported sparc32. >>> >>> I have mixed feelings about this, but it is certainly better than >>> throwing out sparcv8 outright. >> >>>> As pointed out by David Miller, correct support for plain sparcv8 >>>> could really only be provided with kernel supported. And when >>>> it lands on kernel side, it should work effortlessly with a >>>> sparcv8 + cas glibc build. >>> >>> What do you mean by "work effortlessly with a sparcv8 + cas glibc >>> build"? >> >> Meaning that even if underlying hardware does not support correct CAS, >> kernel emulation will provide it and thus a default GLIBC sparc32 build >> will work regardless. > > I am not sure it is as simple as that. Even if the kernel makes sure > that an emulated CAS is atomic against another emulated CAS, it would > not guarantee atomicity against a plain store instruction on a different > CPU, right? For the emulated CAS to work on an SMP system I would think > the atomic_store_relaxed and atomic_store_release functions would also > need to be handled by the kernel, locking the write out when the CAS is > emulated, to keep the interaction linearizable. > I would expect kernel to emulate all the define atomic operation defined in ISA to provide correct atomic semantic. I am not really sure how feasible it would be, but the idea is from library standpoint running on a machine with a emulated atomic provided by kernel is semantic equal to running on a machine with hardware provided atomic. And I think it would be not feasible to keep pushing for C11 atomics on glibc if we can not guarantee it.