<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 - [WinEH] LLVM emits unreachable (incorrect?) RSP adjustments after noreturn calls, like CxxThrowException"
href="https://bugs.llvm.org/show_bug.cgi?id=45064">45064</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[WinEH] LLVM emits unreachable (incorrect?) RSP adjustments after noreturn calls, like CxxThrowException
</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>Windows NT
</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>rnk@google.com
</td>
</tr>
<tr>
<th>CC</th>
<td>craig.topper@gmail.com, hans@chromium.org, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, spatel+llvm@rotateright.com
</td>
</tr></table>
<p>
<div>
<pre>I noticed this while investigating <a class="bz_bug_link
bz_status_CONFIRMED "
title="CONFIRMED - Stack object turned into invalid state during exception-caused stack unwinding"
href="show_bug.cgi?id=45021">https://bugs.llvm.org/show_bug.cgi?id=45021</a>
We've had this bug many times:
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [X68] r270109 can create dead stack adjustments after noreturn calls (previously PR27140)"
href="show_bug.cgi?id=43155">https://bugs.llvm.org/show_bug.cgi?id=43155</a>
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - LLVM generates unreachable call stack adjustments after noreturn functions when the frame is not reserved"
href="show_bug.cgi?id=27117">https://bugs.llvm.org/show_bug.cgi?id=27117</a>
But we still have it. :)
Consider, with EH enabled:
struct MakeCleanup {
~MakeCleanup();
};
bool cond();
void foo() {
MakeCleanup o;
if (cond())
throw;
if (cond())
throw;
}
We get this:
...
callq _CxxThrowException
subq $32, %rsp
.Ltmp7:
jmp .LBB0_8
.LBB0_5: # %if.then3
.Ltmp4:
xorl %ecx, %ecx
xorl %edx, %edx
callq _CxxThrowException
subq $32, %rsp
.Ltmp5:
.LBB0_8: # %unreachable
This is worrying to me, because it could interfere with the Win64 stack
unwinder.
On Win64, most stack frames are reserved, and I think the code we added in the
first place is causing more trouble than it's worth:
if (CLI.DoesNotReturn && !getTargetMachine().Options.TrapUnreachable) {
// No need to reset the stack after the call if the call doesn't return. To
// make the MI verify, we'll pretend the callee does it for us.
NumBytesForCalleeToPop = NumBytes;
}
X86ISelLowering.cpp:4333 (file is too big to link on github)
When EH is involved, it becomes difficult for the code I added to PEI to
determine that this adjustment is after a noreturn function call:
<a href="https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/X86/X86FrameLowering.cpp#L3074">https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/X86/X86FrameLowering.cpp#L3074</a>
I think we might want to invent a cleaner way of indicating that the adjustment
is "dead" and can be skipped while still pacifying the verifier. I notice that
a third argument to ADJCALLSTACKDOWN* was added to pacify the verifier, so we
could do the same again for ADJCALLSTACKUP*.</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>