[MacPorts] #62330: clang-5.0 - clang-11: add emulated_tls functionality to compiler_rt

MacPorts noreply at macports.org
Sat Feb 20 17:30:47 UTC 2021


#62330: clang-5.0 - clang-11: add emulated_tls functionality to compiler_rt
-------------------------------------------------+-------------------------
  Reporter:  kencu                               |      Owner:  (none)
      Type:  defect                              |     Status:  new
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:
Resolution:                                      |   Keywords:
      Port:  libcxx clang-5.0 clang-6.0          |
  clang-7.0 clang-8.0 clang-9.0 clang-10         |
  clang-11 clang-devel                           |
-------------------------------------------------+-------------------------
Description changed by kencu:

Old description:

> To support {{{thread_local_storage}}} in c++ software, 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 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.

New description:

 To support {{{thread_local_storage}}} in c++ software, 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.

--

-- 
Ticket URL: <https://trac.macports.org/ticket/62330#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list