[llvm-dev] LLJIT vs. thread-local storage (again)

[Geoff Levner via llvm-dev]

Hmm, I'm confused. The DSO is compiled with gcc. Do I need to compile
it with clang instead? I don't believe the JITted code uses the thread
support library directly, although I suppose it may be hidden with
templates and/or inline functions...

On Mon, Sep 28, 2020 at 10:43 PM Lang Hames <lhames at gmail.com> wrote:
>
> Hi Geoff,
>
> 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.
>
> This doesn't help you right now, but for what it is worth the road-map to native TLS is becoming clearer:
>
> (1) Land the orcv1-removal branch.
> (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.
> (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.
> (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.
>
> Steps  (1) and (2) are mostly done. Step (3) shouldn't be too difficult. Step (4) will be the interesting part.
>
> -- Lang.
>
> On Mon, Sep 28, 2020 at 7:35 AM Geoff Levner <glevner at gmail.com> wrote:
>>
>> Hi JITters,
>>
>> 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:
>>
>> Symbols not found: [ __emutls_v._ZSt15__once_callable,
>> __emutls_v._ZSt11__once_call ]
>>
>> Those seem to correspond to std::__once_callable and std::__once_call,
>> which are indeed present in the C++ standard library. And I imagine
>> they are needed because the DSO makes calls to std::call_once(). But
>> ORC seems to be looking for them with the prefix "__emutls_v".
>>
>> I had a similar problem in the past, which I thought Lang had fixed...
>> See this thread:
>>
>> http://lists.llvm.org/pipermail/llvm-dev/2020-January/138402.html
>>
>> Perhaps it wasn't as fixed as I thought? Or maybe there is something I
>> need to do for JIT to fully support thread-local storage?
>>
>> Geoff