This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Remove sparcv8 support


On Mon, 2016-11-07 at 11:38 -0500, David Miller wrote:
> 
> So the following attached is what I started playing around with this
> weekend.
> 
> It implements software trap "0x23" to perform a CAS operations, the
> operands are expected in registers %o0, %o1, and %o2.
> 
> Since it was easiest to test I implemented this first on sparc64 which
> just executes the CAS instruction directly.  I'll start working on the
> 32-bit part in the background.
> 
> The capability will be advertised via the mask returned by the "get
> kernel features" system call.  We could check this early in the
> crt'ish code and cache the value in a variable which the atomics can
> check.
> 
> Another kernel side change I have to do is advertise the LEON CAS
> availability in the _dl_hwcaps so that we can use the LEON CAS in
> glibc when available.
> 
> The first patch is the kernel side, and the second is the glibc side.
> The whole NPTL testsuite passes for the plain 32-bit sparc target with
> these changes.

What approach are you going to use in the kernel to emulate the CAS if
the hardware doesn't offer one?  If you are not stopping all threads,
then there could be concurrent stores to the same memory location
targeted by the CAS; to make such stores atomic wrt. the CAS, you would
need to implement atomic stores in glibc to also use the kernel (eg, to
do a CAS).
I didn't see this in the glibc patch you sent, so I thought I'd ask.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]