From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 2454A1F4B5 for ; Tue, 12 Nov 2019 13:36:03 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=c6EK7kNcxhtk1A7e n8liSPmgXSi20urzc8/YZ0ogSUzrOe7PmdEo3h/cVSE7TEoBO0PxQhow0d0nplnm FpjvL20zZ1lMz7qDG1rR6aOIdaBhO+PNiupPD4rJn7noKKV5tWzByMVJ0jvTTS3U fQiE/PTHgPZ3G8Xf+P7FTX0XO+I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=pPk5l8pjlBlCRYE3U5+y9x n5Dik=; b=u0fmtq0Z1s4GBBwy07Dz7HAOGr2tmXpNpOqyz2u5qqYRlbK7gHItaH zYi3FnFntKHUoKoqMF1nXQo52UQ/WRJEQbXCPbQWJ7AFmwjnWw4S7Y+hNBxqtLQb Q7KHiAtFpFeJKxIcXpWaK7SKI1shjftxqcA0aXNUzGUgrxCIY07pg= Received: (qmail 8600 invoked by alias); 12 Nov 2019 13:36:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 8592 invoked by uid 89); 12 Nov 2019 13:36:00 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-wr1-f67.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smile-fr.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5sFoDccTbBSYxBSlQfghpAJAW5BV/C1Bx5D3qlgXVqE=; b=14v8kriwDMPfl6dQ8sEmEX92M7vZG8q6J6JnjNiO5oZPPmzOeI+h9QleREU8diFzDA 4mf5tftqP+3Jx2/St1Wv1dCO+cEMVutKUxR3UKE4dvJdtnLjkj5lB3JDOhqLboBHR9F7 l5CsNSOOz4yZMe145hTUUGdpnau1wdNe/SjtMYX8KatevP6FD1z7/dXfszfWnxDOR1XT 3Q5TzTxVCdXT3bd6dP7o9HEiZrw4WPAAEeejJP7I5Ki2tLgu8Lo31ZMrdaiouNt2MtcX 9MYHaIZjzovD+60G/OsSRmWz3P6FAeBH4d2QctMETjpwCcyk/jx8D5tGezPbAr8vYcJy QmOQ== Subject: Re: [PATCH v2] Remove 32 bit sparc v8 support To: Adhemerval Zanella , libc-alpha@sourceware.org References: <20191111174304.24653-1-adhemerval.zanella@linaro.org> <20191112121731.2670-1-adhemerval.zanella@linaro.org> From: Romain Naour Message-ID: Date: Tue, 12 Nov 2019 14:35:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191112121731.2670-1-adhemerval.zanella@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Adhemerval, Le 12/11/2019 à 13:17, Adhemerval Zanella a écrit : > Changes from previous version: > > - Remove sparc touch files in build-many-glibcs.py. > > -- > > The pthread barrier has no support for sparc v8 since glibc 2.23 > (b02840bacdefd) and although there were some discussion to add > support for LEON chips with CASA instruction [1] discussion has > stalled since. > > If LEON support is still a desirable feature, I would expect to work > towards: > > - Enable USE_ATOMIC_COMPILER_BUILTINS for sparc32. > - Fix the possible instruction emulation code issue on kernel side > (as hinted by David Miller), so even a configuration targetting > LEON would work on sparc v9, although suboptimal. > - Move the generic *.S implementation to multiarch and add adapt > the ifunc selectors. > - Change the required multiarch to use generic implementation for > non v9 case. > - For the assembly specific implementation without ifunc support, > re-evaluate if sparcv9 is really a gain over generic implementation > with current compiler support. > > The patch is straighforward, the sparc v9 is moved as the generic > implementation, the sparc v8 implementations are removed, and a > configure check is added to see if compiler sets __sparcv9__. > > Checked on a sparcv9-linux-gnu. One of my customer is still using sparc v8 LEON cpu on Gaisler's board [1]. Today, I asked him to forward this email to Gaisler in order to have some feedback and maybe some support in upstream Glibc for LEON cpus. For now, only old toolchains using Glibc 2.20 provided by Gaisler are available. I know the sparc v8 support is stalled since glibc 2.23, can we wait before merging this patch? [1] https://www.gaisler.com/index.php/products/operating-systems/linux?task=view&id=63 Best regards, Romain > > [1] https://sourceware.org/ml/libc-alpha/2016-11/msg00027.html > ---