Opened 4 years ago
Closed 4 years ago
#62330 closed defect (invalid)
clang-5.0 - clang-11: add emulated_tls functionality to compiler_rt
Reported by: | kencu (Ken) | Owned by: | kencu (Ken) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | ||
Port: | libcxx clang-5.0 clang-6.0 clang-7.0 clang-8.0 clang-9.0 clang-10 clang-11 clang-devel |
Description (last modified by kencu (Ken))
To support thread_local_storage
in c++ software on systems < 10.7, I added the required emulated_tls bits directly into libc++abi.dylib
. libc++abi.dylib
uses these emulated_tls functions, and copying it into libc++abi.dylib
and leaving it there worked nicely to fill that need.
That also allowed all c++ software to find the needed emulated_tls symbols, as they all link against libc++abi.dylib automatically.
However, this does not allow "C" software to find the emulated_tls symbols anywhere, as "C" software does not automatically link against libc++abi.dylib
.
There have been very rare build failures for this reason, and I have until now worked around them in other ways.
Upstream clang embeds the emulated_tls functions in compiler_rt.a, and they are therefore linked into all builds automatically. The emulated_tls functions are not automatically added to compiler_rt.a
on Darwin, because Darwin >= 10.7 uses a different TLS system (tlv_*).
To support "C" software that uses TLS on < 10.7, you can force it to link against libc++abi.dylib
(abomination, but works to find the symblols), or I can rewrite the compiler_rt cmake build scripts to add the emulated_tls symbols to compiler_rt.a on < 10.7.
The latter is no doubt the better thing, and it is exactly what upstream does on all the other systems without system TLS functionality, or without emulated_tls functionality in libc.
I'm not (at the moment) certain how that might or might not affect what I've already done in libc++abi.dylib
. The reason the symbol was added to libc++abi.dylib
directly is that the build was not using it when it was added to compiler_rt, but the last time I tried this was about 2016.
Change History (5)
comment:1 Changed 4 years ago by kencu (Ken)
Description: | modified (diff) |
---|
comment:2 Changed 4 years ago by kencu (Ken)
Description: | modified (diff) |
---|---|
Owner: | set to kencu |
Status: | new → assigned |
comment:3 Changed 4 years ago by kencu (Ken)
comment:4 Changed 4 years ago by kencu (Ken)
Well, looks like those symbols are actually in there now after all:
/opt/local/libexec/llvm-9.0/lib/clang/9.0.1/lib/darwin/libclang_rt.osx.a(emutls.c.o): 0000000000000000 T ___emutls_get_address 00000000000001a0 t _emutls_init 0000000000000230 d _emutls_init_once.once 00000000000001c0 t _emutls_key_destructor 0000000000000240 d _emutls_mutex 0000000000000318 b _emutls_num_object 0000000000000320 b _emutls_pthread_key
so -- why are they not being linked it then? I will have to look a bit deeper.
comment:5 Changed 4 years ago by kencu (Ken)
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
this becomes relevant now because the lack of the emulated_tls symbols available to "C" software causes a build failure in a planned update to
mesa
20.x.