llvm dev - Sep 2020 - LLJIT vs. thread-local storage (again)

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200928/c14222b8/attachment.html>

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