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

[Ulrich Weigand]

Chandler Carruth <chandlerc at gmail.com> 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
LLVM.

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?

Bye,
Ulrich