<div dir="ltr"><div class="gmail_extra">First off, many thanks for digging through this! =D</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 8:02 AM, Ulrich Weigand <span dir="ltr"><<a href="mailto:Ulrich.Weigand@de.ibm.com" target="_blank">Ulrich.Weigand@de.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":76b" class="a3s" style="overflow:hidden">Chandler, as a workaround it should be possible to use the initial-exec TLS<br>
model for this variable; this should work fine (at least on Linux).   Using<br>
the following line:<br>
<br>
static __thread __attribute__((tls_model("initial-exec"))) const<br>
  PrettyStackTraceEntry *PrettyStackTraceHead = nullptr;<br>
<br>
I was able to complete a bootstrap on powerpc64le-linux (Ubuntu 14.04).</div></blockquote></div><br>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.</div></div>