<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 - Wrong compact unwind information for functions using stack probes"
href="https://bugs.llvm.org/show_bug.cgi?id=46813">46813</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Wrong compact unwind information for functions using stack probes
</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>MacOS X
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Backend: X86
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>alex@crichton.co
</td>
</tr>
<tr>
<th>CC</th>
<td>craig.topper@gmail.com, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, spatel+llvm@rotateright.com
</td>
</tr></table>
<p>
<div>
<pre>In rust-lang/rust we've for the longest time enabled frame pointers on our
macOS targets, but we're looking at that again recently and trying to figure
out why we're still doing this. An attempt to disable frame pointers, however,
led to segfaults during unwinding. We investigated this a bit and came up on
this issue.
The issue here we found is that the compact unwind information for a function
with a large stack frame is incorrect if the "probe-stack" attribute is used.
Namely this IR:
target triple = "x86_64-apple-macosx10.7.0"
define void @foo() #0 {
start:
%_huge_stack = alloca [1024 x i64], align 8
call void @bar()
ret void
}
declare void @bar()
attributes #0 = { uwtable "probe-stack"="__probestack" }
when compiled yields:
$ llc unwind.ll -o foo.o -filetype=obj
$ llvm-objdump foo.o -uS
foo.o: file format mach-o 64-bit x86-64
Disassembly of section __TEXT,__text:
0000000000000000 <_foo>:
./build/bin/llvm-objdump: warning: 'foo.o': failed to parse debug
information for foo.o
0: b8 08 20 00 00 movl $8200, %eax
5: e8 00 00 00 00 callq 0xa <_foo+0xa>
a: 48 29 c4 subq %rax, %rsp
d: e8 00 00 00 00 callq 0x12 <_foo+0x12>
12: 48 81 c4 08 20 00 00 addq $8200, %rsp
19: c3 retq
Unwind info:
Contents of __compact_unwind section:
Entry at offset 0x0:
start: 0x0 _foo
length: 0x1a
compact encoding: 0x03032000
Here the compact unwind information for `foo` is 0x03032000, where the tag
(0x3000000) indicates `UNWIND_X86_64_MODE_STACK_IND`, which according to online
documentation says:
// UNWIND_X86_64_MODE_STACK_IND:
// A "frameless" (RBP not used as frame pointer) function large constant
// stack size. This case is like the previous, except the stack size is too
// large to encode in the compact unwind encoding. Instead it requires that
// the function contains "subq $nnnnnnnn,RSP" in its prolog. The compact
// encoding contains the offset to the nnnnnnnn value in the function in
// UNWIND_X86_64_FRAMELESS_STACK_SIZE.
For this function, however, the `subq` instruction doesn't exist with a
constant, but rather `%rax` which comes from `__probestack`</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>