From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123048 invoked by alias); 21 Nov 2019 19:44:04 -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 123039 invoked by uid 89); 21 Nov 2019 19:44:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-qv1-f67.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:cc:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TxyvdGfWjhcQ39m/hQ+81+T00T92SYEtD53KGOnHT8M=; b=FQeqFspGhxeYXHBO87Lew4ya74z8PigeBmDbCOp1gmgjixolFcu0vBT9wbWC+FlbJn LNR3cX4Sstnh12EXN1TYnP0pIE2Oi1afj9atQsmy60rVMhwGz0wCsu7uSJzkmZ65Ozbi NI+3GbWrA+c72UdHQFiBR53XW9ZEzHKcf/IfRA+q9ooR3rHwbxEyZj3oJbS2f5eSohXD MnGXnnH9N9H9UnLRzR3YxX8hYrKIlHt2x5C1K6if9yvgyoll0rlNh2cVAEeU657F/HIT UlsMyUUuA1MjJ1FITwU1AlJHmdkBx7p+ZdIuSUuoYjr3x4+NrY2OnVmaljmSUz9NY/Ok eppw== Return-Path: To: Andreas Larsson , libc-alpha@sourceware.org Cc: Romain Naour References: <20191113192823.17109-1-adhemerval.zanella@linaro.org> <20191113192823.17109-2-adhemerval.zanella@linaro.org> From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Re: [PATCH 2/2] sparc: Use atomic compiler builtins on sparc Message-ID: <08a0fc90-81ac-d8f9-d3eb-8b89c8fcf6fd@linaro.org> Date: Thu, 21 Nov 2019 19:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2019-11/txt/msg00742.txt.bz2 On 19/11/2019 11:23, Andreas Larsson wrote: > On 2019-11-13 20:28, Adhemerval Zanella wrote: >> This patch removes the arch-specific atomic instruction, relying on >> compiler builtins.  The __sparc32_atomic_locks support is removed >> and a configure check is added to check if compiler uses libatomic >> to implement CAS. >> >> It also removes the sparc specific sem_* and pthread_barrier_* >> implementations.  It in turn allows buidling against a LEON3/LEON4 >> sparcv8 target, although it will still be incompatible with generic >> sparcv9. >> >> Checked on sparcv9-linux-gnu and sparc64-linux-gnu.  I also checked >> with build against sparcv8-linux-gnu with -mcpu=leon3. > > I tested this on LEON vith the nptl-tests, and it works fine! Thanks. > > I still think that it would be useful to have kernel emulation for these > atomics for sparc32 running on v8 or v9 in the future. If not in glibc, > perhaps it could be solved by trapping to the kernel from the compiler > builtins when compiling for Linux, via some option that GLIBC can enable > when building for a new enough kernel. Is there any real plan for a future sparc v8 without proper atomics? Because afaik besides LEON, all current sparc releases from other vendors (including open-source implementation targeting FPGA) supports v9. For a libc standpoint that aims to support both recent C and POSIX standard, an architecture without proper CAS is at least tricky to support. The sparc v7 cas emulation using lock it is not async-signal-safe and it leads to a set of internal possible inconsistencies (besides the scalability issue). Also, the trick proposed by David [1], although clever, just adds internal complexity with much direct gain. It would require to add some compiler switch along with a configure test to to disable the usage of compiler builtins and fallback to the kernel trap. And it would be another build permutation that would need some coverage (at least from build-many-glibcs). It is even messy because a glibc built targetting a sparcv8 won't run on a sparcv9 without an updated kernel. I wouldn't block if such patch is proposed, but I think sparcv8 without atomics is quite unusual that it does not worth the trouble. > > Tested-by: Andreas Larsson [1] https://sourceware.org/ml/libc-alpha/2016-11/msg00243.html