This is the mail archive of the
mailing list for the libc-ports project.
Re: [PATCH] mips: work-around R10k ll/sc errata
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Matt Turner <mattst88 at gmail dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, 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>
- Date: Sat, 30 Jul 2011 21:56:35 +0100 (BST)
- Subject: Re: [PATCH] mips: work-around R10k ll/sc errata
- References: <firstname.lastname@example.org> <Pine.LNX.email@example.com> <BANLkTik66=75x5S7Ah1tuX6v4uTXOi2KVQ@mail.gmail.com> <Pine.LNX.firstname.lastname@example.org> <20110629180430.GA8274@linux-mips.org> <Pine.LNX.email@example.com> <BANLkTimrbv37ByhLOSVd_27JX14XpuMK6g@mail.gmail.com> <CAEdQ38GMFJqnQkC+ZAe-5EOrmaYWxRvkjDJwaHC239x5XdXfkw@mail.gmail.com>
> >>> 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.
I haven't been particularly good at following e-mail recently, sorry.
My understanding is your change merely substitutes ordinary branch with
branch-likely instructions when the code in question is specifically built
with -march=r10000. Well, that's probably about the best that you can do
without hurting the others, and then the code will run correctly on any
newer processors too.
Obviously as some have pointed, it won't run on anything below MIPS IV,
but I think let's just leave the case of compatibility with pre-MIPS-IV
and broken R10000 systems both at once to be sorted out by anyone
interested. And by building with -march=r10000 you get the benefit of
MIPS IV conditional move instructions too (plus some obscure FP extensions
To put it short, I don't have any objections against your change. Again,
sorry about the RTT.