Opened 3 years ago

Closed 3 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 3 years ago by kencu (Ken)

Description: modified (diff)

comment:2 Changed 3 years ago by kencu (Ken)

Description: modified (diff)
Owner: set to kencu
Status: newassigned

comment:3 Changed 3 years ago by kencu (Ken)

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.

Last edited 3 years ago by kencu (Ken) (previous) (diff)

comment:4 Changed 3 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.

Last edited 3 years ago by kencu (Ken) (previous) (diff)

comment:5 Changed 3 years ago by kencu (Ken)

Resolution: invalid
Status: assignedclosed
Note: See TracTickets for help on using tickets.