<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - r298851 breaks code that tries to initialise TLS on aarch64"
href="https://bugs.llvm.org/show_bug.cgi?id=35317">35317</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>r298851 breaks code that tries to initialise TLS on aarch64
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>5.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Backend: AArch64
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>ed@80386.nl
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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:
- <a href="https://github.com/NuxiNL/cloudlibc/blob/master/src/crt/crt0.c#L381-L387">https://github.com/NuxiNL/cloudlibc/blob/master/src/crt/crt0.c#L381-L387</a>
- <a href="https://github.com/NuxiNL/cloudlibc/blob/master/src/common/tls.h#L18-L28">https://github.com/NuxiNL/cloudlibc/blob/master/src/common/tls.h#L18-L28</a>
Initialising TLS objects for the initial thread:
- <a href="https://github.com/NuxiNL/cloudlibc/blob/master/src/crt/crt0.c#L389-L401">https://github.com/NuxiNL/cloudlibc/blob/master/src/crt/crt0.c#L389-L401</a>
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?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>