<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Geoff,<br><div><br></div><div>Sorry -- I misread your question!</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I have some JIT-compiled C++ code that uses symbols from a DSO which uses C++14's thread support library. When I compile it I get the following error message:<br>Symbols not found: [ __emutls_v._ZSt15__once_callable,<br>__emutls_v._ZSt11__once_call ]</blockquote></div><div><br></div><div>That error message implies that your JIT'd code is directly referencing a TLS variable, but the definition of the TLS variable has not been compiled with -femulated-tls.</div><div><br></div><div>Did you expect your JIT'd code to reference call_once? Or was this perhaps due to some unexpected inlining?</div><div><br></div><div>If JIT'd code doesn't access TLS variables at all then you don't have to worry about -femulated-tls. If JIT'd code uses TLS variables (either defining or referencing them) then you need to turn -femulted-tls on for the JIT'd code and any libraries that define TLS variables used by JIT'd code. Unfortunately this can snowball: Once the library is complied with emulated-tls, if it depends on TLS variables in a second library then that also needs to be compiled with -femulated-tls, and so on.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I had a similar problem in the past, which I thought Lang had fixed...</blockquote><div><br></div><div>That was a different emulated-tls problem: The JIT tracks symbol definitions very carefully to ensure that they're not dropped (or error out if they are) and the implicit renaming used by -femulated-tls was breaking this. The fix taught the JIT to anticipate the renaming in order to fix the tracking. This allows -femulated-tls to be used in JIT'd code. but you still need to use it consistently across library boundaries.</div><div><br></div><div>Native TLS should fix this whole mess once we can support it.</div><div><br></div><div>-- Lang.</div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 28, 2020 at 2:02 PM Geoff Levner <<a href="mailto:glevner@gmail.com" target="_blank">glevner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hmm, I'm confused. The DSO is compiled with gcc. Do I need to compile<br>
it with clang instead? I don't believe the JITted code uses the thread<br>
support library directly, although I suppose it may be hidden with<br>
templates and/or inline functions...<br>
<br>
On Mon, Sep 28, 2020 at 10:43 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br>
><br>
> Hi Geoff,<br>
><br>
> If you want to access the variable directly from JIT'd code you will need to compile the DSO with -femulated-tls. Alternatively you could introduce a wrapper function to return the variable's address.<br>
><br>
> This doesn't help you right now, but for what it is worth the road-map to native TLS is becoming clearer:<br>
><br>
> (1) Land the orcv1-removal branch.<br>
> (2) Land the ORC remote-target-support branch -- This breaks ORC up into three libraries: One for the JIT, one for the target process and one of shared data structures.<br>
> (3) Create an ORC runtime library. I'm not sure whether this should live in LLVM or compiler-rt, but it would include implementations of, among other things, native TLS variable setup.<br>
> (4) Teach JITLink to handle native TLS relocations. This should be relatively straightforward on MachO. It may be more involved for ELF, but I haven't had a chance to dig in to this yet.<br>
><br>
> Steps  (1) and (2) are mostly done. Step (3) shouldn't be too difficult. Step (4) will be the interesting part.<br>
><br>
> -- Lang.<br>
><br>
> On Mon, Sep 28, 2020 at 7:35 AM Geoff Levner <<a href="mailto:glevner@gmail.com" target="_blank">glevner@gmail.com</a>> wrote:<br>
>><br>
>> Hi JITters,<br>
>><br>
>> I have some JIT-compiled C++ code that uses symbols from a DSO which<br>
>> uses C++14's thread support library. When I compile it I get the<br>
>> following error message:<br>
>><br>
>> Symbols not found: [ __emutls_v._ZSt15__once_callable,<br>
>> __emutls_v._ZSt11__once_call ]<br>
>><br>
>> Those seem to correspond to std::__once_callable and std::__once_call,<br>
>> which are indeed present in the C++ standard library. And I imagine<br>
>> they are needed because the DSO makes calls to std::call_once(). But<br>
>> ORC seems to be looking for them with the prefix "__emutls_v".<br>
>><br>
>> I had a similar problem in the past, which I thought Lang had fixed...<br>
>> See this thread:<br>
>><br>
>> <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-January/138402.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2020-January/138402.html</a><br>
>><br>
>> Perhaps it wasn't as fixed as I thought? Or maybe there is something I<br>
>> need to do for JIT to fully support thread-local storage?<br>
>><br>
>> Geoff<br>
</blockquote></div>