Incorrect local-dynamic TLS linker optimization with clang-generated code on PowerPC
Ulrich Weigand
Ulrich.Weigand at de.ibm.com
Thu Jan 29 06:44:14 PST 2015
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
sets
> > > register r29, while the linker-generated replacement sets r3.
Looking at
> > > the linker code, the addis "r3, r13, ..." seems to be simply
hard-coded,
> > > which works only if the original instruction sets register r3.
> >
> > Ouch. Will fix.
>
> Fixed with https://sourceware.org/ml/binutils/2015-01/msg00318.html
Thanks!
> > > 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.
Bye,
Ulrich
More information about the llvm-commits
mailing list