Re: [PATCH v2] Remove 32 bit sparc v8 support

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 12/11/2019 12:39, Andreas Larsson wrote:
> On 2019-11-12 13:17, Adhemerval Zanella wrote:
>> 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.
> 
> Thank you for bringing this issue up again. We would like to solve this
> issue, as it is stopping us and our LEON3/4 users of using newer
> versions of GLIBC without local patches, which is very troublesome.
> 
> Our patch in [1] aimed to be an initial solution to this issue for LEON,
> however it turned out that it has problems for cases when sparc v9 could
> not be detected.
> 
>>
>> 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.
> 
> Do you mean that the a sparc v9 would trap on a LEON CASA instruction
> and the kernel would deal with it? If so, the problem with that approach
> is that a CASA instruction aimed for LEON will be an incorrect CASA on
> sparc v9 (and vice versa). It would not trap in a well defined way where
> we can let the kernel take over. This is why David Miller suggested the
> solution mentioned in [2], where glibc would via _dl_hwcap use LEON CASA
> when we know we are on a CASA-capable LEON, use v9 CASA when we know we
> are on sparc v9 and an explicit trap in other cases, letting the kernel
> emulate.
> 
> We can start work towards this by submitting a Linux kernel patch adding
> a hwcap bit to distinguish a CASA-capable LEON and submitting a glibc
> RFC-patch like the one in [1] (using sparc v9 CASA when we know are on
> sparc v9) with the change that we use LEON CASA only when knowing via
> _dl_hwcap that we are on a CASA-capable LEON and trapping with ta 0x23
> otherwise.
> 
> This would make glibc build for sparc32 and work on sparc v9 and
> CASA-capable LEONs (when we know that we are on one of those cases). It
> would if all goes right also work without changes on sparc v8 (and sparc
> v9/LEON when we do not know about it) has soon as the kernel has been
> updated.
> 
> David Miller started the work on handling emulation via trap 0x23 in the
> Linux kernel for sparc v9 (can be seen in [3]). We are willing to test
> the emulation for sparc v8 if Dave wants to handle the implementation,
> or to pitch in on the implementation side if need be.
> 
> 
> [1] https://sourceware.org/ml/libc-alpha/2016-11/msg00027.html
> [2] https://sourceware.org/ml/libc-alpha/2016-11/msg00197.html
> [3] https://sourceware.org/ml/libc-alpha/2016-11/msg00243.html

The direction I would like to make sparc and other ports to move is to
have a streamline build where glibc relies as less as possible on
arch-specific code.  It allows consolidate as much as code as possible,
incurs in less maintainability, and leverages compiler improvements.

Also, sparc32 has the __sparc32_atomic_locks where besides adding some 
contention, I think is not fully async-signal-safe and making recursive
is not really an improvement.  By Removing it allow us to use U
SE_ATOMIC_COMPILER_BUILTINS and thus simplify the internal atomic 
definitions.

I think it is better than rely on a kernel assisted helper, as David 
Miller suggested, which for sparc v8 I think it is not possible to 
implement in userspace as ARM v5 and earlier and it inherent a performance
hit with a software trap.

So one possible solution to still support LEON3/4, while still
simplifying sparc code base would be to:

  1. Refactor the sparc atomic to use USE_ATOMIC_COMPILER_BUILTINS
     and a configure test to refuse compiler configuration that emit
     libatomic calls.  This should create the expected atomic
     instructions calls on both sparcv9 and leon3/4.

  2. Remove the non required sparc32 lowlevellock.{c,h}.

  3. Move the sysdeps/sparc/sparc32/sparcv8/*.S to sysdeps/sparc/sparc32.

  4. Move both the sysdeps/sparc/sparc32/sparcv9/{mem,str,stp}*.S and
     sysdeps/sparc/sparc32/sparcv9/multiarch to sysdeps/sparc/sparc32/multiarch/
     and refactor ifunc selectors to use the sparcv8 as default and the
     sparcv9 as the HWCAP_SPARC_V9 options.

     4.1. As a side-note some implementations (such as strcat, strcspn, strspn,
	  and strpbrk) mostly likely does not worth the trouble and the generic 
	  implementation could be an improvement.

     4.2. For pthread_spin_* I would check if generic implementation could not
          be used instead (since it uses atomic operation and these would be
          created by the compiler options used to build glibc).

  5. Same as 4. for sparcv9 fpu folder.

  6. bactrace.h, cpu_relax.c, and hp-timing will need be consolidate with 
     compiler conditionals, as other architectures (hp-timing s390 for instance).


I think 1. and 2. would be the required steps to enable LEON3/LEON4 support,
but 3-6 would be good to cleanup the sparc clutter.

With these the glibc build for leon3 will be still incompatible with generic
sparcv8/sparcv9, but without a proper way to check at runtime (such as a hwcap
bit) which atomic instruction is actually supported by underlying hardware the 
other options are not really an improvement (trap on sigill for instance).

> 
> 
> Best regards,
> 
> Andreas Larsson
> Software Engineer
> Cobham Gaisler
> 
>>   - 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.
>>
>> [1] https://sourceware.org/ml/libc-alpha/2016-11/msg00027.html
>