<html>
    <head>
      <base href="https://llvm.org/bugs/" />
    </head>
    <body><span class="vcard"><a class="email" href="mailto:rnk@google.com" title="Reid Kleckner <rnk@google.com>"> <span class="fn">Reid Kleckner</span></a>
</span> changed
              <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - [WinEH] x64 UnwindHelp offset is wrong for realigned stack frames"
   href="https://llvm.org/bugs/show_bug.cgi?id=25514">bug 25514</a>
        <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">Status</td>
           <td>NEW
           </td>
           <td>RESOLVED
           </td>
         </tr>

         <tr>
           <td style="text-align:right;">Resolution</td>
           <td>---
           </td>
           <td>FIXED
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - [WinEH] x64 UnwindHelp offset is wrong for realigned stack frames"
   href="https://llvm.org/bugs/show_bug.cgi?id=25514#c3">Comment # 3</a>
              on <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - [WinEH] x64 UnwindHelp offset is wrong for realigned stack frames"
   href="https://llvm.org/bugs/show_bug.cgi?id=25514">bug 25514</a>
              from <span class="vcard"><a class="email" href="mailto:rnk@google.com" title="Reid Kleckner <rnk@google.com>"> <span class="fn">Reid Kleckner</span></a>
</span></b>
        <pre>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</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>