Remove sparcv8 support

  On 2016-10-24 19: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.

Yes, it is apparent that we need to keep up better to avoid problems
like this.

>> 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

and fixing missing undefs for sparc32 for sendmsg and recvmsg
(sparc32 was not adjusted in commit abf29edd4a3918)


made me able to cross-compile glibc 2.24 using gcc 4.9.4 and
-mcpu=leon3, boot with a buildroot based system and run cross-compiled
nptl/tst-barrier[1234] without failures. I will continue with building
and run the rest of the test framework, especially tst-barrier5.

Best regards,
Andreas Larsson
  

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).