<html>
<head>
<base href="http://llvm.org/bugs/" />
</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 --- - post-RA scheduler breaks unwinding through indirect calls"
href="http://llvm.org/bugs/show_bug.cgi?id=22015">22015</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>post-RA scheduler breaks unwinding through indirect calls
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</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: PowerPC
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jay.foad@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=13588" name="attach_13588" title="test case">attachment 13588</a> <a href="attachment.cgi?id=13588&action=edit" title="test case">[details]</a></span>
test case
With the attached test case I get:
$ llc -O2 -o - a.ll
[...]
f: # @f
.align 3
.quad .L.f
.quad .TOC.@tocbase
.quad 0
.text
.L.f:
.cfi_startproc
# BB#0:
mflr 0
std 0, 16(1)
stdu 1, -128(1)
.Ltmp0:
.cfi_def_cfa_offset 128
.Ltmp1:
.cfi_offset lr, 16
.Ltmp2:
.cfi_offset r30, -16
addis 4, 2, .LC1@toc@ha
std 30, 112(1) # 8-byte Folded Spill
mr 30, 3
ori 2, 2, 0
ld 4, .LC1@toc@l(4)
ld 12, 0(4)
std 2, 40(1)
ori 2, 2, 0
ld 4, 0(12)
ld 11, 16(12)
ld 2, 8(12)
mtctr 4
bctrl
mr 3, 30
ld 2, 40(1)
[...]
At this point, just after the indirect call to *g, the TOC pointer is reloaded
from the stack into r2. The problem is that the system unwinder in libgcc only
recognises this if the "ld r2,40(r1)" instruction is *immediately* after the
call instruction. In this case the post-RA scheduler has moved things around so
that it is not.
This breaks a bunch of asan test cases on PowerPC64 when the asan runtime is
built with clang, because asan's __interceptor___cxa_throw is affected by the
bug.
AddressSanitizer-Unit ::
Asan-powerpc64-inline-Test/AddressSanitizer.CxxExceptionTest
AddressSanitizer-Unit ::
Asan-powerpc64-with-calls-Test/AddressSanitizer.CxxExceptionTest
AddressSanitizer-Unit ::
Asan-powerpc64le-inline-Test/AddressSanitizer.CxxExceptionTest
AddressSanitizer-Unit ::
Asan-powerpc64le-with-calls-Test/AddressSanitizer.CxxExceptionTest
AddressSanitizer64 :: TestCases/contiguous_container.cc
AddressSanitizer64 :: TestCases/throw_call_test.cc
AddressSanitizer64 :: TestCases/throw_catch.cc
AddressSanitizer64 :: TestCases/uar_and_exceptions.cc</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>