Re: Remove sparcv8 support

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

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?

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.

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.