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