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

[Lang Hames via llvm-dev]

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>