search for: __emutls_v

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 wit...

...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...

...ction returns the address of this said variable. As mention this code is compiled with clang-cl for windows in 64bit, generating a BC file. When loading this file with my JIT-Client I get some undefined references which I could resolve - besides from two: "__emutls_get_address" and "__emutls_v.xyz_" (xyz is just a place holder - don't remember what was written there) I tried researching a bit and... I think this functions are related to emulating TLS? So I look into the IR file but noticed that these function where not mentioned there. So I assumed they must be created by the...

...ory sanitizer: — still tries to partially instrument the blacklisted code; — does not check whether its global memory storage variables are already defined. The second issue, present in MemorySanitizer::initializeCallbacks, adds a second copy of storage global variables when compiling msan.cc (e.g. __emutls_v.__msan_retval_tls.63, __emutls_v.__msan_param_tls.65), and this results in an undefined reference during the linkage. Here the question is what was initially intended to be done. I know that compiling blacklisted asan runtime code with -fsanitize=address is just fine, and this is what Apple actual...

> Unfortunately it doesn't look like lli has support for emulated TLS either, though that would be pretty simple to add. As an experiment I've `llvm::createLowerEmuTLSPass` into lli which added @__emutls_v.x and @__emutls_v.t. However i didn't have any __emultls_get_address calls in my IR. Is there a llvm pass or compiler-flag that replaces thread_locals with appropriate __emultls_get_address calls ? 2017-02-08 14:53 GMT+00:00 Tim Northover <t.p.northover at gmail.com>: > On 8 Februa...

...ies to partially instrument the blacklisted code; > — does not check whether its global memory storage variables are already > defined. > The second issue, present in MemorySanitizer::initializeCallbacks, adds a > second copy of storage global variables when compiling msan.cc (e.g. > __emutls_v.__msan_retval_tls.63, __emutls_v.__msan_param_tls.65), and this > results in an undefined reference during the linkage. > > Here the question is what was initially intended to be done. I know that > compiling blacklisted asan runtime code with -fsanitize=address is just > fine, and t...

...trument the blacklisted code; >> — does not check whether its global memory storage variables are already >> defined. >> The second issue, present in MemorySanitizer::initializeCallbacks, adds a >> second copy of storage global variables when compiling msan.cc (e.g. >> __emutls_v.__msan_retval_tls.63, __emutls_v.__msan_param_tls.65), and this >> results in an undefined reference during the linkage. >> >> Here the question is what was initially intended to be done. I know that >> compiling blacklisted asan runtime code with -fsanitize=address is just...

...t;>>> 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 __emutls_v.xyz was not found (substitute the mangled >>>> variable name for "xyz"). >>>> >>>> Does that mean anything to anybody out there? >>>> >>>> (I don't know if it's relevant, but we are using LLVM 8, and we are >>>&g...

...t;>>> 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 __emutls_v.xyz was not found (substitute the mangled >>>> variable name for "xyz"). >>>> >>>> Does that mean anything to anybody out there? >>>> >>>> (I don't know if it's relevant, but we are using LLVM 8, and we are >>>&g...

...ve 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 __emutls_v.xyz was not found (substitute the mangled >>>>>> variable name for "xyz"). >>>>>> >>>>>> Does that mean anything to anybody out there? >>>>>> >>>>>> (I don't know if it's relevant, but we are...

...e file a bug and CC me. Issue #2: Emulated TLS and name mangling (raised by Geoff Levner on llvm-dev): Use of emulated-tls affects the name mangling of LLVM IR symbols. For a thread local symbol with name <Name>, when emulated-tls is enabled we will produce at least one emulated-tls symbol: __emutls_v.<Name> (which must then be linker-mangled to get the final symbol name). If that symbol has a non-zero initializer a second symbol will also be produced: __emutls_t.<Name>. ORCv2 requires up-front specification of the exact set of linker-level symbol names that a module produces, so tha...

Argh. Thanks for the info. We're on Linux. On Fri, Dec 20, 2019 at 3:46 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Hi Geoff, > Gathering from past, I remember that the ORCv2 doesn't support thread > local variable but not sure what is the current status now. What platform > you are on? > CC'ed (Lang hames) he knows exactly what is the

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 https://reviews.llvm.org/D8815, but then we went a different direction with TLS in our frontend and it became unnecessary. On Fri, Dec 20, 2019 at 12:36 PM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +Lang

What exactly do the compiler flags`-femulated-tls` and `tls-model` do ? Why does tls-emulation not solve the problem ? Looking at the generated IR, it seems not to remove thread_local variable declarations. What is the reasoning behind that ? 2017-02-07 16:27 GMT+00:00 Gaetano Checinski <gaetano.checinski at gmail.com>: > > got a minimal example now: > extern thread_local