Re: Remove sparcv8 support

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2016-10-25 at 16:33 +0200, Andreas Larsson wrote:
> On 2016-10-24 19:25, Torvald Riegel wrote:
> > On Fri, 2016-10-21 at 10:59 +0200, Andreas Larsson wrote:
> >> 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.
> 
> Perhaps not the kosher way to do it (happy to get feedback if some
> other method should be used), but changing
> sysdeps/sparc/sparc32/pthread_barrier_wait.c to:
> 
> #if defined(__GCC_ATOMIC_INT_LOCK_FREE) && (__GCC_ATOMIC_INT_LOCK_FREE > 1)
> #include <nptl/pthread_barrier_wait.c>
> #else
> #error No support for pthread barriers on pre-v9 sparc.
> #endif

The sparc-specific barriers should just go away. atomic-machine.h for
sparc v8 should ensure that it provides the atomic operations that are
needed (and which work on process-shared uses too).

I don't have a real preference for when in the build process we should
check whether a real CAS is provided by the HW (eg, at configure time or
when trying to use atomic operations).

I'd suggest to also look at whether you really need the custom spinlock
on sparc; the generic ones should be just as good (if not, it would be
good to have a comment in the custom files explaining why we need
those).  Also, is the barrier in
sysdeps/sparc/sparc64/pthread_spin_trylock.S at the right position wrt.
to the actual acquisiton of the lock? (OTOH, I think we assume TSO
anyway, so a misplaced acquire or release MO fence is harmless).