[llvm-bugs] [Bug 35317] New: r298851 breaks code that tries to initialise TLS on aarch64

[via llvm-bugs]

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

            Bug ID: 35317
           Summary: r298851 breaks code that tries to initialise TLS on
                    aarch64
           Product: libraries
           Version: 5.0
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: AArch64
          Assignee: unassignedbugs at nondot.org
          Reporter: ed at 80386.nl
                CC: llvm-bugs at lists.llvm.org

On CloudABI, I've observed crashes of processes on AArch64 when using Clang
5.0, though Clang 4.0 works perfectly fine. This is due to the changes made in
SVN r298851.

On CloudABI, crt0 is responsible for allocating TLS and updating TPIDR_EL0
accordingly. Once completed, it will initialise some of the objects stored in
TLS for the initial thread.

Setting up TLS:
- https://github.com/NuxiNL/cloudlibc/blob/master/src/crt/crt0.c#L381-L387
- https://github.com/NuxiNL/cloudlibc/blob/master/src/common/tls.h#L18-L28

Initialising TLS objects for the initial thread:
- https://github.com/NuxiNL/cloudlibc/blob/master/src/crt/crt0.c#L389-L401


With the changes made in r298851, mrs TPIDR_EL0 is marked as having no
side-effects whatsoever. This is too strong, because an msr TPIDR_EL0 can
affect the register's value. In other words, it is all right to combine and
reorder mrs TPIDR_EL0 instructions, but we shouldn't be doing this across the
msr.

I can imagine that the optimisation provided by r298851 would be worth having.
If we want to leave it intact, wouldn't it make more sense to revert to the old
behaviour, but assume that functions called in other compilation units will not
clobber TPIDR_EL0?

If it is hard to fix this on short notice, could we please revert this change
for 5.0.1?

-- 
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/20171115/8a36ecc4/attachment.html>