[llvm-bugs] [Bug 52497] New: Merge b8f04a670f27a84412099dd025fa762ee58f4c1a into 13.0.1

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=52497

            Bug ID: 52497
           Summary: Merge b8f04a670f27a84412099dd025fa762ee58f4c1a into
                    13.0.1
           Product: compiler-rt
           Version: unspecified
          Hardware: All
                OS: OpenBSD
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: builtins
          Assignee: unassignedbugs at nondot.org
          Reporter: brad at comstyle.com
                CC: llvm-bugs at lists.llvm.org
            Blocks: 52147

Please merge
https://github.com/llvm/llvm-project/commit/b8f04a670f27a84412099dd025fa762ee58f4c1a.

[PATCH] [builtins] Try to ensure single copy of emulated TLS state

Multiple copies of emulated TLS state means inconsistent results when
accessing the same thread-local variable from different shared objects
(https://github.com/android/ndk/issues/1551). Making `__emutls_get_address`
be a weak default visibility symbol should make the dynamic linker
ensure only a single copy gets used at runtime. This is best-effort, but
the more robust approach of putting emulated TLS into its own shared
object would (a) be a much bigger change, and (b) shared objects are
pretty heavyweight, and adding a new one to a space-constrained
environment isn't an easy sell. Given the expected rarity of direct
accesses to emulated TLS variables across different shared objects, the
best-effort approach should suffice.


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=52147
[Bug 52147] [meta] 13.0.1 Release Blockers
-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20211113/749ffe35/attachment.html>