This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] sparc: Use atomic compiler builtins on sparc
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 <andreas@gaisler.com>
[1] https://sourceware.org/ml/libc-alpha/2016-11/msg00243.html