From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16660 invoked by alias); 21 Oct 2016 13:13:27 -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 16650 invoked by uid 89); 21 Oct 2016 13:13:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=2.20, fulfill, baseline, customers X-HELO: mail-vk0-f42.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=CFrJnVL9Cbu7Ehwk9rBMWyrkdAx2s9WLozNbzjND1Uw=; b=A6h3xhSP6euY9urjd8P63jhd3QOSK2I7Er4I+HbHC9hiG55fhwJ9PCPF3VXAAtJiw3 /avU014BxvXXq+gWKR9OcCHAxzKDVg6Z0teJYoVTLfMsJAlL/YN5RtmpoKbN7kdjGZ5d jLZKPeHpShcq7a1fM7kb8+WnXN179eqmn4inknNshYFl0oPQAWn7YOmtc/+WfxS+2G0E thQGbWc0bQ2ql3WywklzZcog8ced3BGYfPqF4rQLdDlOcop3rJgTAp1LtsBP63opvDZu ji6zFKx4lz9fXy/UAbG/TTDIIEC4SXvX8UtfjQKi87MWQLoaa4zTJo+JqIRuYpVPus95 KSTA== X-Gm-Message-State: ABUngvc6VjqIdWDHXzHSLPHlUQbbtktcVAHlbKeMq7LP6485hFnNU5zhEI9iDsHpvL+FF8nH X-Received: by 10.31.226.66 with SMTP id z63mr611902vkg.103.1477055594624; Fri, 21 Oct 2016 06:13:14 -0700 (PDT) Subject: Re: Remove sparcv8 support To: Andreas Larsson , GNU C Library References: <48cdf008-b66a-d411-a07a-5a38595978b9@linaro.org> <5809D90E.1090005@gaisler.com> Cc: David Miller From: Adhemerval Zanella Message-ID: <2ebab6ef-3ca4-9ee5-3158-488f368b8a8d@linaro.org> Date: Fri, 21 Oct 2016 13:13: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: <5809D90E.1090005@gaisler.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-10/txt/msg00352.txt.bz2 On 21/10/2016 06:59, 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. > > 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.) I am glad I could get some attention. At least for glibc, building with '-mcpu=leon3' will enable both sparcv9 and fpu implied folders, so I think we do not have problem here (unless glibc preconfigure and config.guess is wrongly assuming leon3 as sparcv9 compatible for glibc implementations). Now the current problem for pre sparc-v9 is on 'New pthread_barrier algorithm to fulfill barrier destruction requirements.' (commit id b02840bacdefde318d2ad2f920e50785b9b25d69) Torvald's added a default sparc32 pthread_barrier_wait.c file to just throw an build error. This is because new algorithm uses atomic_compare_exchange_weak_release and for pre-v9 sparc32 it will have to use a lock embedded into the barrier (as for previous implementation). Ideally we would like to do in a way that can be embedded into the generic code so that you don't have to maintain sparc-specific files. I am not sure which will pre-v9 sparc specific constraints, but my understanding is you will need to extend the 'struct pthread_barrier' so 'current_round' will be at least 64-bits so you can use '__v7_compare_and_exchange_val_acq' (I am also not sure about alignment requirement). Which get back to initial proposal: do we really care to continue support sparc variants without proper CAS implementation? For each new NPTL or other implementation we will need to take pre-sparcv8 in consideration and I feel that current sem_xxx implementation is still lacking the latest fixes. If you still care for such support, we need to set a track date for completion. It has been 2 releases that we ship broken pre-sparcv8 support and see no point on continue to do so.