search for: femul

...irectly, 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-targe...

...ad_local . All that being sorted out, we now have libc++ 7.0.0 and libc++abi built and being used with emulated-tls support on darwin < 11 now. Thanks! The last bit of this I plan to sort out would be how to tweak the following patch so that __cxa_thread_atexit would be called based on the -femulated-tls flag rather than based on the MacOSXVersion. That way emulated-tls could be used/tested on any OS version. -- Ken ========================== --- a/tools/clang/lib/CodeGen/ItaniumCXXABI.cpp.orig 2018-10-02 18:31:17.000000000 -0700 +++ b/tools/clang/lib/CodeGen/ItaniumCXXABI.cpp 2018-10-02...

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

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

On 2018-12-08 19:10, Ken Cunningham via llvm-dev wrote: > So putting it into libc++abi.dylib might indeed be the only workable method, assuming each executable would get it's own copy in memory and they wouldn't all collide together. Can ibc++abi link with libclang_rt to resolve the symbol? -- /Jacob Carlborg

...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 February 2017 at 04:57, Gaetano Checinski > <gaetano.checinski at gmail.com> wrote: > > What exactly do the compiler flags`-femulated-tls` and `tls-model` do ? > > Why does tls-emulation not solve the problem ? > > It requires runtime support, specifically the __emultls_get_address > function by the looks of it. That's not available on all platforms > (it's not supplied by macOS for example) and is l...

...xternc-isystem //Users/dingbaozeng/Library/Android/sdk/ndk-bundle/sysroot/usr/include -Os -Wno-invalid-command-line-argument -Wno-unused-command-line-argument -Wno-error=format-security -w -fdebug-compilation-dir /Users/dingbaozeng/work/native_obfuscator/tests -ferror-limit 19 -fmessage-length 138 -femulated-tls -stack-protector 2 -fno-signed-char -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -mllvm -indibran -o ./busybox//obj/local/armeabi-v7a/objs/busybox/archival/bzip2.o -x c busybox/archival/bzip2.c 1. <eof> parser at end of file 2. Cod...

...rs/dingbaozeng/Library/Android/sdk/ndk-bundle/sysroot/usr/include -Os > -Wno-invalid-command-line-argument -Wno-unused-command-line-argument > -Wno-error=format-security -w -fdebug-compilation-dir > /Users/dingbaozeng/work/native_obfuscator/tests -ferror-limit 19 > -fmessage-length 138 -femulated-tls -stack-protector 2 -fno-signed-char > -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics > -vectorize-loops -vectorize-slp -mllvm -indibran -o > ./busybox//obj/local/armeabi-v7a/objs/busybox/archival/bzip2.o -x c > busybox/archival/bzip2.c > > 1. <eof>...

> I’ve seen the same problem, but didn’t find solution back then. > I can give a hint that it is related to a thread local storage (notice TLS in the name). > > The same result can be reproduced by this simple program: > > thread_local int x = 0; > int main() { > return 0; > } > >When compiled into IR it produces similar error: > >LLVM ERROR:

Dear lots of people, The first comments on the 3.7 release expressed surprise that there were no changes to the X86 or ARM targets. There had of course been a lot of hard work and many changes, but none of it was mentioned in the release notes. Please help make the release notes more comprehensive this time. The notes are of course not as important as the actual code, but they do get read, and