Add support for native TLS on OS X

[jacob-carlborg]

Second try at implementing native TLS on OS X. See #1461 for reference.

[yebblies]

Conflict! Please rebase the dmd one too.

[jacob-carlborg]

Rebased.

[jacob-carlborg]

@smolt will this work for ARM as well?

[yebblies]

https://auto-tester.puremagic.com/?projectid=10

[jacob-carlborg]

😃 thanks.

[smolt]

@jacob-carlborg if you mean could it work on ARM by adding version flags for CPU, probably yes as long as built with modified LLVM with TLS support for iOS (https://github.com/smolt/iphoneos-apple-support). When this merges into LDC, we'll have to decide if should switch over to this upstream module instead of ldc specific module.

[jacob-carlborg]

@smolt Since you added version identifiers for the non OS X platforms I was wondering if it was correct with the X86 and X86_64 version identifiers.

[smolt]

Ah that. Yes, that is correct. Dmd can build for the iOS, tvOS, and watchOS simulators as they are x86 and x86_64 based.

[schveiguy]

I can no longer build druntime or phobos unit tests with clang. Note, there is an issue with clang with this code, I'm working on a PR to fix this, but of course, don't want to submit without unittests running :)

Error:

Undefined symbols for architecture x86_64:
  "dyld_enumerate_tlv_storage(void (dyld_tlv_states, dyld_tlv_info const*) block_pointer)", referenced from:
      _d_dyld_getTLSRange(void*, void**, unsigned long*) in osx_tls.o
  "__d_dyld_getTLSRange", referenced from:
      _D2rt19sections_osx_x86_6413initTLSRangesFZAv in test_runner.o
  "_getErrno", referenced from:
      _D4core4stdc5errno5errnoFNbNdNiNeZi in test_runner.o
  "_setErrno", referenced from:
      _D4core4stdc5errno5errnoFNbNdNiNeiZi in test_runner.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any ideas?

[jacob-carlborg]

That looks really strange. Looks like some mangling issue. Have you tried making clean builds of both the compiler and druntime?

[jacob-carlborg]

It works fine for me. Which version of Xcode, Clang and OS X are you using?

[schveiguy]

OK, I figured it out.

On my system, CC by default is c++. This compiles the .c files as C++ files. Obviously this screws up the linkage.

I'm so not good at makefile-fu, so someone is going to have to fix this other than me.

[schveiguy]

Nevermind. I had CC set in my environment. Not sure why, but I fixed it now. Pretend I didn't spew all that idiotic stuff ;)

[schveiguy]

Note, there is an issue with clang with this code, I'm working on a PR to fix this

Note, this was also caused by my errant environment. So false alarm there too...

[jacob-carlborg]

You can also run nm generated/osx/release/64/osx_tls.o. This is the result I get:

                 U __NSConcreteStackBlock
0000000000000070 t ____d_dyld_getTLSRange_block_invoke
                 U ___assert_rtn
00000000000007e0 s ___block_descriptor_tmp
0000000000000000 T __d_dyld_getTLSRange
                 U _dyld_enumerate_tlv_storage

[jacob-carlborg]

Ok, cool. No worries 😃.

[jacob-carlborg]

BTW, Clang will give you a warning if you try to compile C files with clang++, unless it's suppressed somewhere in the makefile.

[schveiguy]

Clang will give you a warning

haha, this is exactly why I noticed it. In fact, my first attempt to "fix" that warning was to rename to cpp :)

Of course, one becomes numb to these types of warnings, especially when one doesn't work with the code in question. We have warnings all over the place in dmd for example :)

[jacob-carlborg]

haha, this is exactly why I noticed it. In fact, my first attempt to "fix" that warning was to rename to cpp

Haha 😃.

We have warnings all over the place in dmd for example

Very true.