This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH] mips: work-around R10k ll/sc errata
- From: Matt Turner <mattst88 at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Ralf Baechle <ralf at linux-mips dot org>, libc-ports at sourceware dot org, Joshua Kinard <kumba at gentoo dot org>, Tom de Vries <tom at codesourcery dot com>, macro at linux-mips dot org
- Date: Thu, 28 Jul 2011 01:45:26 -0400
- Subject: Re: [PATCH] mips: work-around R10k ll/sc errata
- References: <1309298625-31737-1-git-send-email-mattst88@gmail.com> <Pine.LNX.4.64.1106291431110.28272@digraph.polyomino.org.uk> <BANLkTik66=75x5S7Ah1tuX6v4uTXOi2KVQ@mail.gmail.com> <Pine.LNX.4.64.1106291616320.28272@digraph.polyomino.org.uk> <20110629180430.GA8274@linux-mips.org> <Pine.LNX.4.64.1106291930450.679@digraph.polyomino.org.uk> <BANLkTimrbv37ByhLOSVd_27JX14XpuMK6g@mail.gmail.com>
On Thu, Jun 30, 2011 at 1:17 PM, Matt Turner <mattst88@gmail.com> wrote:
> On Wed, Jun 29, 2011 at 3:34 PM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
>> On Wed, 29 Jun 2011, Ralf Baechle wrote:
>>
>>> > I didn't get any sense of consensus in the previous discussion (which
>>> > extended to at least Jan 2009) and several people there are rather more
>>> > expert in the MIPS variants than me. ?Perhaps someone would care to put
>>> > together a compilation of all the points raised and explain how the patch
>>> > addresses them or at least leaves things no worse off - in particular
>>> > detailing the circumstances (compiler options) under which the patch
>>> > results in any change to the code in glibc.
>>>
>>> Do you have a pointer to that old discussion?
>>
>> http://sourceware.org/ml/libc-ports/2008-10/msg00010.html
>> http://sourceware.org/ml/libc-ports/2008-11/subjects.html#00000
>> http://sourceware.org/ml/libc-ports/2009-01/subjects.html#00036
>>
>>> To summarize, I think the patch should be applied but the mentioned issues
>>> may deserve documentation.
>>
>> Thanks. ?Maciej, do you have any comments on this latest patch?
>>
>>> As more of a general question, Is there a point in eventually moving this
>>> sort of stuff into a VDSO? ?It would allow the kernel to provide suitable
>>> definitions of common LL/SC constructs without having to modify glibc.
>>
>> I don't think it's easy for GCC to generate calls to a vDSO directly from
>> __sync_* intrinsics, and __sync_* intrinsics (or in future an
>> implementation of the C1X and C++0X atomics functionality using new
>> versions of those intrinsics) are what we want code to use.
>
> I don't mean to speak for Maciej, but in the last email link you
> provided, both he and Daniel Jacobowitz seem to be in favor of a patch
> that only affected the code when specifically requested.
>
>> Please don't activate this workaround on builds that won't run on an R10K
>
> Matt
So it doesn't look like we should be expecting a response from Maciej
anytime soon.
The patch only modifies behavior when specifically prompted, namely
-march=r10k, and Ralf says it should be applied. I don't see any
obstacles, really.
Thanks,
Matt