thread_local storage on 10.6.8 (and earlier) with clang-7.0

[Ken Cunningham]

> At present I don't seem to know enough about the underpinnings to see how to change the visibility settings on the emutls objects from libclang_rt when placed into the executable.

I think I'm possibly getting my head around this...

___emutls_get_address is not hidden in libclang_rt, it's visible:

$ nm /opt/local/libexec/llvm-5.0/lib/clang/5.0.1/lib/darwin/libclang_rt.10.4.a  | grep emu
/opt/local/libexec/llvm-5.0/lib/clang/5.0.1/lib/darwin/libclang_rt.10.4.a(emutls.c.o):
0000000000000000 T ___emutls_get_address


but when that code is incorporated into the executable, the symbol is (by design) not exported beyond the executable, so libc++abi.dylib will never see it.

$ nm 4 | grep emu
0000000100007070 t ___emutls_get_address


and I am actually not sure that it is possible to have executables export symbols for linked libraries to call into. It would be probably bad, even if you could force it.

So perhaps having emutls.c in libclang_rt can never actually work...maybe the emutls.o code needs to exist in a separate dylib (like it does in libgcc).

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.

Ken