
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">Hi Geoff,<div><br></div><div>Ok — I think I’m caught up now. You’re using LLVM 8, and thread locals are working for you on ORCv1, but not ORCv2.</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Is there any chance that ORC v2 will support thread-local variables in the foreseeable future?</div></div></blockquote><div><br></div></div><div>I think so. I was able to reproduce an issue that looks related to yours on my Darwin machine:</div><div><br></div><div><div><font face="Courier New"><span style="font-style: normal;">In <main> resolving { ("___emutls_v.x": 0x000000012a406000 [Data]), ("___emutls_t.x": 0x000000012a406020 [Data]), ("_main": 0x000000012a405000 [Callable]) }</span></font></div><div><font face="Courier New"><span style="font-style: normal;">Assertion failed: (I != SymbolFlags.end() && "Resolving symbol outside this responsibility set"), function notifyResolved, file llvm/li</span></font><span style="font-family: "Courier New";">b/ExecutionEngine/Orc/Core.cpp, line 448.</span></div></div><div><br></div><div>If I look at what was supposed to be resolved (the “responsibility set”) I see that the JIT expected a definition for _x, but instead it got an unexpected definition for __emutls_t.x. You’re seeing the reverse: the JIT linker is trying to resolve __emutls_t.x (presumably you’ve compiled some code with an extern therad_local reference), but the JIT only knows about _x.</div><div><br></div><div>The reason for the change in behavior has to do with concurrency support, which was introduced in ORCv2. To make concurrency safe you need to declare the symbols that any program representation will produce up front (So we can know which program representation to compile, kick off its compilation, and synchronize around it). Usually, knowing what symbols a program representation will produce is easy: You just mangle all the defined symbol names and you’re done. In this case though emulated TLS will rename some symbols during compilation. I think the solution is to teach the JIT to mangle IR thread-local names (with an _emutls_t. prefix) when emulated TLS is enabled. I will take a shot at this tomorrow.</div><div><br></div><div>— Lang.</div><div><br></div><div>Sent from my iPad</div><div><div dir="ltr"><br><blockquote type="cite">On Jan 7, 2020, at 2:29 AM, Geoff Levner <glevner@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>So, picking up this thread again after the holidays (burp)... Is there any chance that ORC v2 will support thread-local variables in the foreseeable future? Is there some way of configuring it today to ensure they are handled correctly? Or are we better off sticking with ORC v1?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 20, 2019 at 9:59 PM Jameson Nash via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I don't think it's especially hard, but just not specifically unimplemented because nobody's had a strong need for it. There's probably some combinations of code models and machines that does happen to work (e.g. emutls+linux+large-code+large-data+no-PIC). Julia has some support for thread locals, but as a JIT in control of the language we currently try to generate better code than would otherwise happen (often bits of inline assembly that's more similar to the initial-exec model than a dynamic library would normally be able to use)—but also with more limitations on how it may be used and requiring some additional support from the runtime.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 20, 2019 at 1:17 PM Praveen Velliengiri <<a href="mailto:praveenvelliengiri@gmail.com" target="_blank">praveenvelliengiri@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Jameson,</div><div>Why thread local support is hard to support in JITs? Whether Julia supports Thread locals? If so, it would be very much helpful to know how.</div><div><br></div><div>Thanks<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 20 Dec 2019 at 23:31, Jameson Nash via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">This had also came up at llvm-devmtg briefly at the JIT roundtable. One of the collaborators on my project had started a patch years ago to implement some of it <a href="https://reviews.llvm.org/D8815" target="_blank">https://reviews.llvm.org/D8815</a>, but then we went a different direction with TLS in our frontend and it became unnecessary.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 20, 2019 at 12:36 PM David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">+Lang for visibility<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 20, 2019 at 5:09 AM Geoff Levner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">I am in the process of porting our ORC code to ORC v2 and LLJIT. Now that I have worked around a problem getting global constructors to be called, everything seems to work unless a module declares a static thread-local variable. In that case I get a "JIT session error" saying that the symbol __<a href="http://emutls_v.xyz" target="_blank">emutls_v.xyz</a> was not found (substitute the mangled variable name for "xyz").</div><div dir="ltr"><br></div><div>Does that mean anything to anybody out there?</div><div><br></div><div>(I don't know if it's relevant, but we are using LLVM 8, and we are using Clang to compile C++ modules that are all put into a single JITDylib.)</div><div><br></div><div>Geoff<br>

</div></div></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div></div>

</div></blockquote></div></div></body></html>