Incorrect local-dynamic TLS linker optimization with clang-generated code on PowerPC

Chandler Carruth chandlerc at
Wed Jan 28 16:32:27 PST 2015

On Wed, Jan 28, 2015 at 1:18 PM, Ulrich Weigand <Ulrich.Weigand at>

> Chandler Carruth <chandlerc at> wrote:
> > This works for folks linking LLVM statically into the executable,
> > but my understanding is that it doesn't work in other cases (some
> > folks dlopen LLVM). I'm going to try forcing it to always be general
> > dynamic and precluding local dynamic on PPC64 so we actually get the
> > function call. If that makes the bots happy, I'll use that.
> > Otherwise, the options become either using initial-exec and breaking
> > dlopens or hacking back in pthread TLS under a macro. Hoping to
> > avoid the latter as I'd like to use raw TLS in a few other places in
> Well, initial-exec *should* usually work even with dlopen, since glibc will
> over-allocate the initial TLS areas on startup, exactly so that dlopen'ed
> libraries can use a bit of initial-exec space if that is critical to their
> performance.  There isn't a lot of space available but a single
> initial-exec
> pointer in a library usually works ...
> However, making it general-dynamic should also work, and is probably
> the better solution (stack dumping is not performance critical and should
> not use up space reserved for performance critical things ...).
> 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?

Well, either setting it to global-dynamic doesn't work, or the bug persists:

I think that as of that build the attribute is spelled and set up nicely,
and it still explodes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the llvm-commits mailing list