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

[Andreas Larsson <andreas at gaisler dot com>]

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


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