This is the mail archive of the
mailing list for the glibc project.
Re: Remove sparcv8 support
- From: Andreas Larsson <andreas at gaisler dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, GNU C Library <libc-alpha at sourceware dot org>, David Miller <davem at davemloft dot net>, "software at gaisler dot com" <software at gaisler dot com>
- Date: Tue, 01 Nov 2016 16:26:44 +0100
- Subject: Re: Remove sparcv8 support
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <5809D90E.email@example.com> <firstname.lastname@example.org> <email@example.com> <580F6D5E.firstname.lastname@example.org> <D71809D1-BF0B-408B-83CB-DA25FB56ACDF@linaro.org> <5810C1A3.email@example.com> <firstname.lastname@example.org>
On 2016-10-27 12:38, Torvald Riegel wrote:
On Wed, 2016-10-26 at 16:45 +0200, Andreas Larsson wrote:
On 2016-10-25 16:44, Adhemerval Zanella wrote:
On 25 Oct 2016, at 12:34, Andreas Larsson <email@example.com> wrote:
On 2016-10-24 19:42, Adhemerval Zanella wrote:
On 24/10/2016 15:25, Torvald Riegel wrote:
On Fri, 2016-10-21 at 10:59 +0200, Andreas Larsson wrote:
On 2016-10-20 21:47, Adhemerval Zanella wrote:
The sparcv8 build is broken since GLIBC 2.23 due the new pthread
barrier implementation  and since then there is no thread or
interest on fixing it (Torvald has suggested some options on
2.23 release thread). It won't help with both new pthread rdlock
and cond implementation, although I would expect that it relies
on same atomic primitive that was not present for pthread barrier.
AFAIK, recent commercial sparc chips from Oracle all supports
sparcv9. The only somewhat recent sparc chip with just sparcv8
support is LEON4, which I really doubt it cares for glibc support.
We do care about GLIBC support for many different LEON3 and LEON4
systems. GLIBC support for sparcv8 is important for us and it is
important for our customers. Both LEON3 and LEON4 are continuously used
in new hardware designs.
If you do care about it, it would be nice if you could (help) maintain
sparcv8 (e.g., regularly testing most recent glibc on sparcv8, at the
very least early during the freeze of each release). This ensures that
you won't get surprises such as this one, when nobody else is spending
resources on it.
We are not always using the latest version of GLIBC (the latest step we
took was to GLIBC 2.20), so unfortunately we missed this issue. We will
look into what the extent of the missing support is. Any pointers are
Do you have a link to the suggested options on the 2.23 release thread?
I dug around a bit in the archives, but did not find it.
(As a side note, most of the recent LEON3 and LEON4 chips have CAS
instruction support, but pure sparcv8 support is of course the baseline.)
Yes, the lack of CAS is the major problem I am aware of. If the chips
you mention do support CAS, then a patch that adds support for the
CAS-based atomic operations in glibc would fix the barrier problem
(because the generic barrier should just work). The patch would also
have to add configure bits or whatever would be appropriate so that
glibc can figure out whether it is supposed to be run on a sparcv8 with
or without CAS.
What about stopping support for plain sparcv8, and keeping to support
sparcv8+CAS provided that we have a (group of) maintainer(s) for the
latter that can tend to the minimal responsibilities of an arch
maintainer and has the time to do that?
At least the build for sparcv9-linux-gnu with -mcpu=leon3 finishes,
although I am not sure if it correctly runs on leon processors.
And I seconded Tovarld's suggestion about stop maintaining plain
sparcv8 and set sparcv8+CAS as the base supported sparc32.
I have mixed feelings about this, but it is certainly better than
throwing out sparcv8 outright.
As pointed out by David Miller, correct support for plain sparcv8
could really only be provided with kernel supported. And when
it lands on kernel side, it should work effortlessly with a
sparcv8 + cas glibc build.
What do you mean by "work effortlessly with a sparcv8 + cas glibc
Meaning that even if underlying hardware does not support correct CAS,
kernel emulation will provide it and thus a default GLIBC sparc32 build
will work regardless.
I am not sure it is as simple as that. Even if the kernel makes sure
that an emulated CAS is atomic against another emulated CAS, it would
not guarantee atomicity against a plain store instruction on a different
CPU, right? For the emulated CAS to work on an SMP system I would think
the atomic_store_relaxed and atomic_store_release functions would also
need to be handled by the kernel, locking the write out when the CAS is
emulated, to keep the interaction linearizable.
Is there still recent sparcv8 hardware that has no native CAS but
multiple CPU cores? I think we've used the kernel emulation only on
non-multi-core systems so far.
There are no LEON3 or LEON4 multiprocessor chips that I am aware of that
lacks CAS. I cannot rule out that some customer has instantiated such a