similar to: using emulated-tls on Darwin 8, 9, 10

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

> On 2018-12-07 22:30, Ken Cunningham via llvm-dev wrote: >> Please excuse hobbiest-level question. >> Darwin 11+ enables thread_local variables using system-level supports. >> I have an interest in enabling TLS on darwin < 11 using emulated-tls. > > Is anyone still running macOS 10.6 or older? > > -- > /Jacob Carlborg > [off topic, apologies] Yes,

On 2018-12-08, at 2:27 PM, Ken Cunningham wrote: > And then we should be in business, and all systems will have thread_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

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

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

Nick, How exactly do you envision this being done? Looking at the contents of config/darwin.h, I see... /* Support -mmacosx-version-min by supplying different (stub) libgcc_s.dylib libraries to link against, and by not linking against libgcc_s on earlier-than-10.3.9. Note that by default, -lgcc_eh is not linked against! This is because in a future version of Darwin the EH frame

Hello again! Tried out the small Hello World Setup, worked as intended: root at christian-forschung-virtual-machine:/home/progs# clang -v --target=arm-linux-gnueabihf hello.c -o hello -fuse-ld=lld clang version 8.0.0 (https://git.llvm.org/git/clang.git/ a152c7a4b7ba8f4cb9532ead9a38a7121db43d50) (https://git.llvm.org/git/llvm.git/ 1959ce6f3e01241919968ac1911fd45660239d23) Target:

Hello Peter and Lists, thanks a lot, that way it worked out! The final cmake was cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF -DCMAKE_C_COMPILER=/usr/local/myclang/bin/clang -DCMAKE_AR=/usr/local/myclang/bin/llvm-ar

Jack, I think there is an extra dimension to darwin that might be confusing things. Darwin uses two-level-name-space. That means that at build time the linker records where it found each dylib (SO) symbol. (It records the path the dylib supplied as its "install name" - not just the leafname as SO_NEEDED does.) On a SnowLeopard system you *can* link against /usr/lib/libgcc_s.

Hello again Christian, I've posted https://reviews.llvm.org/D55709 to see if we can get the documentation on how to cross-compile compiler-rt improved. I'll be out of office until next year so I may be a bit slow to respond to any follow ups. Peter On Thu, 13 Dec 2018 at 17:10, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Christian, > > I've just

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

On Fri, Sep 18, 2009 at 10:28:15AM -0700, Nick Kledzik wrote: > So, when these test cases are run, is the binary linked against /usr/ > lib/libgcc_s.10.5.dylib? or against some just built libgcc_s.10.5.dylib? > or against some just build libgcc_s.dylib? If either of the latter, then > if you changed the FSF build of libgcc_s for darwin to have the right > magic symbols, then

Hello Christian, I've put some comments inline, On Sun, 3 Feb 2019 at 13:11, Christian Richter <christian.richter at hsu-hh.de> wrote: > > Hello again, > > so after I successfully build the compiler-rt for armv6 I tried to > actually use it in compiling a small helloworld for a baremetal arm > (consisting of barehelloCLANG.c and a small io.h + io.c) , but the >

Hello Christian, I'd expect that adding the library paths (-L) from gcc -v should fix the unable to find -lc, -lm but it won't fix the -lclang_rt.builtins-armv6m.a . To get clang_rt.builtins-armv6m.a you will need to cross compile compiler-rt for v6m and copy it to /usr/local/myclang/lib/clang/8.0.0/lib/baremetal . Beware that building compiler-rt for v6m does need quite a bit of fighting

On 26 August 2015 at 20:13, Jason Kim <jasonk at codeaurora.org> wrote: > I had been discussing the TSAN on android/aarch64 issues with the folks at thread-sanitizer at googlegroups.com for several months now. I had not explicitly been including llvm-dev (and you), and that was a mistake on my part. Palm-on-face? :-( Yup, that would have saved a lot of emails... :) > Patch Size!

Hello Christian, I reran my script with a similar cmake command to yours. After the build finished the following command from the build directory gave me: find . -name \*builtins.a ./lib/clang/9.0.0/armv6m-none-eabi/lib/libclang_rt.builtins.a ./lib/clang/9.0.0/armv7m-none-eabi/lib/libclang_rt.builtins.a ./lib/clang/9.0.0/armv7em-none-eabi/lib/libclang_rt.builtins.a I hope you see something like

It is my pleasure to announce that LLVM 3.8.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

It is my pleasure to announce that LLVM 3.8.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

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

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