This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Remove sparcv8 support
On Fri, 2016-10-21 at 11:02 -0400, David Miller wrote:
> From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> Date: Fri, 21 Oct 2016 11:13:09 -0200
>
> > 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 would not put that into a generic implementation, such a scheme
> deadlocks in the presence of signals.
>
> And yes the existing sparc v7 locking deadlocks this way as well and
> has done so since day one, many of the threaded test cases in glibc
> timeout and fail for this very reason.
>
> The only long term solution is to do what ARM and others have done
> which is provide an atomic primitive in the Linux kernel which
> executes via a system call or similar which will eliminate the signal
> based deadlocks.
I think this is reasonable. Should we stop supporting pre-v9 sparc32
until such a kernel-side solution is in place (and we can test whether
it is present)?
If the specific arch one is building for has CAS, we could also continue
to support it with that as a prerequisite.