[llvm-bugs] [Bug 25514] [WinEH] x64 UnwindHelp offset is wrong for realigned stack frames

[via llvm-bugs]

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

Reid Kleckner <rnk at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Reid Kleckner <rnk at google.com> ---
I fixed this for C++ EH with r253059.

LLVM classifies an alloca as static if it has a constant size and is in the
entry block, so your highly aligned dynamic allocas could become static through
normal optimization.

Anyway, I think fixing the CLR side of things is going to require a different
approach from UnwindHelp. I used a fixed offset stack object which is very far
from SP-after-prologue. The CLR eventually wants to use a stack offset that is
very near SP-after-prologue, so that it can minimize the size of funclet
frames.

The problem is that our realignment prologue looks like this:

SUB RSP, NN
.seh_endprologue <-- SP after prologue is set here
AND RSP, -Alignment
# Address locals from RSP offset zero

So, storing something to SP-after-prologue is very likely to conflict with
local variables, which are allocated starting from SP-after-alignment.

Changing LLVM to not use .seh_setframe would help solve this problem. If we had
a prologue like this we could easily allocate an extra slot after the aligned
local variables:

SUB RSP, LocalSize+Alignment
LEA RBP, [LocalSize+RSP]
AND RBP, Alignment
.seh_endprologue

-- 
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/20151113/3bbd9cf2/attachment.html>