Incorrect local-dynamic TLS linker optimization with clang-generated code on PowerPC
chandlerc at google.com
Thu Jan 29 15:31:03 PST 2015
And FYI, I've removed the attribute to try to force TLS models in r227511.
Thanks to everyone tracking down this twisty maze of interactions.
On Thu, Jan 29, 2015 at 6:44 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com>
> Alan Modra <amodra at gmail.com> wrote on 29.01.2015 03:50:58:
> > On Thu, Jan 29, 2015 at 08:28:17AM +1030, Alan Modra wrote:
> > > On Wed, Jan 28, 2015 at 05:02:06PM +0100, Ulrich Weigand wrote:
> > > > Note how the original instruction marked with R_PPC64_GOT_TLSLD16_LO
> > > > register r29, while the linker-generated replacement sets r3.
> Looking at
> > > > the linker code, the addis "r3, r13, ..." seems to be simply
> > > > which works only if the original instruction sets register r3.
> > >
> > > Ouch. Will fix.
> > Fixed with https://sourceware.org/ml/binutils/2015-01/msg00318.html
> > > > There is also a linker optimination for the general-dynamic case, but
> > > > from reading the BFD sources this seems to work correctly for any
> > > > target register and doesn't just assume r3. Alan, is that right?
> > >
> > > No, I think that is also broken.
> > Actually, looking at it again after I'd woken up properly, the general
> > dynamic case is good.
> Actually, experiment shows that it was broken after all :-)
> More specifically, the general-dynamic to *local-exec* optimization
> was broken, since it uses the same code path as the local-dynamic
> to local-exec optimization. There is a separate general-dynamic to
> initial-exec optimization, which ought to be fine.
> But with Chandler's change, the linker actually used the general-dynamic
> to local-exec optimization (since the output is an executable file, and
> not a shared library), and thus it is still broken.
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits