This is the mail archive of the
mailing list for the glibc project.
Re: sparc nptl mystery resolved
- From: David Miller <davem at davemloft dot net>
- To: roland at hack dot frob dot com
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 27 Jun 2014 15:58:31 -0700 (PDT)
- Subject: Re: sparc nptl mystery resolved
- Authentication-results: sourceware.org; auth=none
- References: <20140627221551 dot 9B3052C39BC at topped-with-meat dot com>
From: Roland McGrath <firstname.lastname@example.org>
Date: Fri, 27 Jun 2014 15:15:51 -0700 (PDT)
> Incidentally, the "sparc-specific" code is so similar to the stock code
> that I'd suggest you do some refactoring so it can share most of the source
> instead of duplicating it. But I haven't looked at all the details, so
> maybe it's less similar than I think.
The difference is that for sparc 32-bit we put an explicit byte
spinlock into the semaphore structures since pre-v9 32-bit we lack
atomic operations other than "ldstub" (load and store byte atomic).
That's also why we have the funny 24-bit atomic integers, so we can
use the upper 8-bits for the byte spinlock.
This strategy, of cource, has a whole host of issues. Worst of which
is that we can (and do) deadlock with signals.
I wish Jakub Jelink and I had to foresight decades ago to do what
other platforms do to handle this situation, which is to have kernel
calls which provide atomic operations. :-/
> On the roland/nptl branch there are a few nptl/ test failures in the
> sparc-linux build that don't show up in the sparcv9-linux build. I presume
> those were preexisting problems and nobody was testing it or caring.
Those, I am pretty sure, were existing problems.