This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports 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: [PATCH] mips: work-around R10k ll/sc errata


Hi Matt,

> >>> 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 
IIRC). :)

 To put it short, I don't have any objections against your change.  Again, 
sorry about the RTT.

  Maciej


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