search for: emutl

...nts. Even PowerPC systems get frequent tickets at MacPorts, and we support them as we can. Some versions of clang will run on PowerPC Macs with workable coverage (in fact the only remaining hole is a persisting issue with a bad address for c++ exceptions being supplied). [/on topic] Making the emutls objects in libclang_rt visible to libcxxabi.dylib at runtime has been a hiccup, tho. It works but seems a shame to hack emutls.c into the libc++abi code when the objects are already sitting there in the executable, but (AFAICT) have the wrong visibility setting to allow use. At present I don'...

...libgcc , thread_local support is available. (In MacPorts, this is done using -stdlib=macports-libstdc++, which links against a new version of libgcc from gcc8). I would like to enable this while using libc++ as well, however. To do this, libc++abi is built with cxa_thread_atexit.cpp added, and emutls.c is built and used in libclang_rt.10.4.a. However I am having an issue wherein the symbol ___emutls_get_address from lilbclang_rt_10.4.a is not visible to libc++abi.dylib at runtime. "___emutls_get_address" is built into clang_rt: $ nm /opt/local/libexec/llvm-5.0/lib/clang/5.0.1/li...

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

...folks: it's no longer behind a flag; would be great to get some notes on this. - Artem: there's been a bunch of CUDA patches. Anything that should be mentioned in the release notes? - Jordan & Anna: any new checkers that should be mentioned? - Chih-Hung: should the notes mention the emutls-style TLS model? - Lang: you did a lot of work on the Kalidoscope tutorial. Maybe we should mention that? .. tell me what I missed :-) Thanks, Hans [1]. http://llvm.org/pre-releases/3.8.0/#rc2.

I don't think it's especially hard, but just not specifically unimplemented because nobody's had a strong need for it. There's probably some combinations of code models and machines that does happen to work (e.g. emutls+linux+large-code+large-data+no-PIC). Julia has some support for thread locals, but as a JIT in control of the language we currently try to generate better code than would otherwise happen (often bits of inline assembly that's more similar to the initial-exec model than a dynamic library would...

...version-compare(>= 10.6 mmacosx-version-min= -lgcc_s.10.5) \ -lSystem -lgcc}" or could we even use... %:version-compare(>= 10.6 mmacosx-version-min= -lgcc_s.10.5) \ -lSystem -lgcc_s}" I think the second case would solve the outstanding issue of the TLS emutls not being linked in on darwin... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888 which would definitely be nice and take a lot of the testsuite out of the unsupported result mode. If anyone would like to propose a specific patch, I would be more than happy to test it against current gcc tru...

...ill be some variant of the problem from before: Using a x86-header where an ARM one would be needed. The ninja builtins output: root at christian-forschung-virtual-machine:/home/llvm_all/buildrtonly# ninja builtins [147/207] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o FAILED: lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o /usr/local/myclang/bin/clang --target=arm-linux-gnueabihf -DVISIBILITY_HIDDEN --target=arm-linux-gnueabihf -march=armv7a -Wall -Wno-unused-parameter -fno-lto -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-fra...

...before: Using a x86-header where an ARM one would be needed. >> >> The ninja builtins output: >> >> root at christian-forschung-virtual-machine:/home/llvm_all/buildrtonly# ninja builtins >> [147/207] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o >> FAILED: lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o >> /usr/local/myclang/bin/clang --target=arm-linux-gnueabihf -DVISIBILITY_HIDDEN --target=arm-linux-gnueabihf -march=armv7a -Wall -Wno-unused-parameter -fno-lto -std=c11 -fPIC -fno-builtin -fvisibility=hi...

...on-min= -lgcc_s.10.5) \ > -lSystem -lgcc}" > > or could we even use... > > %:version-compare(>= 10.6 mmacosx-version-min= -lgcc_s.10.5) \ > -lSystem -lgcc_s}" > > I think the second case would solve the outstanding issue of the > TLS emutls not being linked in on darwin... > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888 > > which would definitely be nice and take a lot of the testsuite > out of the unsupported result mode. > If anyone would like to propose a specific patch, I would be > more than happy to...

...e: Using a x86-header where an ARM one would be needed. > > > > The ninja builtins output: > > > > root at christian-forschung-virtual-machine:/home/llvm_all/buildrtonly# ninja builtins > > [147/207] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o > > FAILED: lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o > > /usr/local/myclang/bin/clang --target=arm-linux-gnueabihf -DVISIBILITY_HIDDEN --target=arm-linux-gnueabihf -march=armv7a -Wall -Wno-unused-parameter -fno-lto -std=c11 -fPIC -fno-builtin -fvisibility=...

On Wed, Aug 19, 2015 at 1:15 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 19 August 2015 at 11:29, Dmitry Vyukov <dvyukov at google.com> wrote: >> Wait, this change is not submitted yet, right? Or you mean mailing of >> this change in bad shape? > > Right. > > Jason has submitted high quality patches before, so this is in no way > a reprimand

...hen targeting 10.6, the linker will ignore those > dylibs and record that the symbols should be found in > /usr/lib/libSystem.B.dylib at runtime. > I'll double check but I believe that the testsuite always links the libgcc_s.10.5.dylib built by the FSF gcc build. The problem with the emutls symbols if I recall correctly is that those are not exposed through libgcc_s.10.5 but rather libgcc_s directly. For now, it would be better to ignore the emults issues and focus on what needs to be done to fix the unwinding. I guess you are saying we need to move the unwinders symbols out into a l...

...ould be needed. > >>> > >>> The ninja builtins output: > >>> > >>> root at christian-forschung-virtual-machine:/home/llvm_all/buildrtonly# ninja builtins > >>> [147/207] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o > >>> FAILED: lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o > >>> /usr/local/myclang/bin/clang --target=arm-linux-gnueabihf -DVISIBILITY_HIDDEN --target=arm-linux-gnueabihf -march=armv7a -Wall -Wno-unused-parameter -fno-lto -std=c11 -fPIC -fno-built...

...of the problem from before: Using a x86-header where an ARM one would be needed. > > The ninja builtins output: > > root at christian-forschung-virtual-machine:/home/llvm_all/buildrtonly# ninja builtins > [147/207] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o > FAILED: lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o > /usr/local/myclang/bin/clang --target=arm-linux-gnueabihf -DVISIBILITY_HIDDEN --target=arm-linux-gnueabihf -march=armv7a -Wall -Wno-unused-parameter -fno-lto -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fo...

...Dan's recent push to android. https://android-review.googlesource.com/#/c/167420/ I asked somewhere else, but, will this give you a reasonably looking thread state without resorting to pthread_get/specific calls? Will this be a unique and non-redundant state for each thread? > 4. use the emutls work http://reviews.llvm.org/D12001 I only suggested this because Joerg/Dan mentioned it. I haven't looked at that patch in detail. From what I'm seeing, options 1 and 3 above may very well suit us. > TESTS! > Currently, about 2/3 tests for tsan fail/flake on android+aarch64. &gt...

...of the problem from before: Using a x86-header where an ARM one would be needed. > > The ninja builtins output: > > root at christian-forschung-virtual-machine:/home/llvm_all/buildrtonly# ninja builtins > [147/207] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o > FAILED: lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/emutls.c.o > /usr/local/myclang/bin/clang --target=arm-linux-gnueabihf -DVISIBILITY_HIDDEN --target=arm-linux-gnueabihf -march=armv7a -Wall -Wno-unused-parameter -fno-lto -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fo...

....0 is now available! Get it here: http://www.llvm.org/releases/download.html#3.8.0 This release contains the work of the LLVM community over the past six months: deprecated autoconf build, shrink-wrapping on by default, overhauled MSVC-compatible exception handling, updated Kaleidoscope tutorial, emutls, OpenMP supported by default, as well as improved optimizations, many bug fixes, and more. Release notes for more details: http://llvm.org/releases/3.8.0/docs/ReleaseNotes.html http://llvm.org/releases/3.8.0/tools/clang/docs/ReleaseNotes.html Huge thanks to everyone who helped with testing, bug...

....0 is now available! Get it here: http://www.llvm.org/releases/download.html#3.8.0 This release contains the work of the LLVM community over the past six months: deprecated autoconf build, shrink-wrapping on by default, overhauled MSVC-compatible exception handling, updated Kaleidoscope tutorial, emutls, OpenMP supported by default, as well as improved optimizations, many bug fixes, and more. Release notes for more details: http://llvm.org/releases/3.8.0/docs/ReleaseNotes.html http://llvm.org/releases/3.8.0/tools/clang/docs/ReleaseNotes.html Huge thanks to everyone who helped with testing, bug...

This is currently a rough area in our build system, but there are two CMake options you probably need to set. (1) -DLLVM_BUILD_EXTERNAL_COMPILER_RT=On —> This option causes the build to use the just-built clang when building compiler-rt (2) -DCOMPILER_RT_DEFAULT_TARGET_ARCH=??? —> This is where you specify which architecture you want to build the compiler-rt archives and libraries for

This may be that the libgcc_s.dylib based unwinder is incompatible with the darwin unwinder. You cannot mix and match the two. One of the lines from the bugzilla comments shows: /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, being used. That will not work. All of the libgcc_s.dylib functionality has been subsumed into libSystem.dylib on SnowLeopard (darwin10). The