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 [1] 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.
Hi!
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
most welcome.
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?