llvm dev - Dec 2018 - using emulated-tls on Darwin 8, 9, 10

> 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, there remains a surprising amount of interest in these systems. MacPorts
sees very frequent user tickets about them, many tickets lately about
thread_local. All versions of clang/llvm run on 10.5+ Intel systems with minor
tweaks, including the latest trunk versions, and  this enables almost all
current opensource software to be used on these systems. Software (like
browsers) geared to these systems see downloads in the low thousands per
release. I guess people either have a need for these systems for some software
version or workflow, or have otherwise workable hardware that as been obsoleted
by newer os requirements.

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

Appreciate any thoughts on this, thanks for your interest, and sorry for the
slight divergence above.

Ken (MacPorts dev)

On 2018-12-08, at 8:06 AM, Ken Cunningham wrote:

> 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

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