Re: Remove sparcv8 support

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 21/10/2016 06:59, 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.
> 
> 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.)

I am glad I could get some attention.  At least for glibc, building
with '-mcpu=leon3' will enable both sparcv9 and fpu implied folders,
so I think we do not have problem here (unless glibc preconfigure and
config.guess is wrongly assuming leon3 as sparcv9 compatible for
glibc implementations).

Now the current problem for pre sparc-v9 is on 'New pthread_barrier 
algorithm to fulfill barrier destruction requirements.' (commit id 
b02840bacdefde318d2ad2f920e50785b9b25d69) Torvald's added a default
sparc32 pthread_barrier_wait.c file to just throw an build error.

This is because new algorithm uses atomic_compare_exchange_weak_release and
for pre-v9 sparc32 it will have to use a lock embedded into the barrier
(as for previous implementation). Ideally we would like to do in a way that
can be embedded into the generic code so that you don't have to maintain 
sparc-specific files.

I am not sure which will pre-v9 sparc specific constraints, but my understanding
is you will need to extend the 'struct pthread_barrier' so 'current_round'
will be at least 64-bits so you can use '__v7_compare_and_exchange_val_acq'
(I am also not sure about alignment requirement).

Which get back to initial proposal: do we really care to continue support
sparc variants without proper CAS implementation? For each new NPTL or other
implementation we will need to take pre-sparcv8 in consideration and
I feel that current sem_xxx implementation is still lacking the latest 
fixes.

If you still care for such support, we need to set a track date for
completion.  It has been 2 releases that we ship broken pre-sparcv8 support
and see no point on continue to do so.