<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [ARM] REGRESSION(r189575): It made 2860 tests fail/crash on AArch64 Linux"
   href="https://bugs.webkit.org/show_bug.cgi?id=149061#c3">Comment # 3</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [ARM] REGRESSION(r189575): It made 2860 tests fail/crash on AArch64 Linux"
   href="https://bugs.webkit.org/show_bug.cgi?id=149061">bug 149061</a>
              from <span class="vcard"><a class="email" href="mailto:msaboff&#64;apple.com" title="Michael Saboff &lt;msaboff&#64;apple.com&gt;"> <span class="fn">Michael Saboff</span></a>
</span></b>
        <pre>While debugging the callee saves work, I would run into failures on release builds that wouldn't reproduce with debug builds.  Typically this was due to the optimizer making use of callee saves registers in the compiled C++ code.  If JSC inadvertently stepped on one of those registers, it would only cause a problem on release builds.

The first place I would look is in the FTL code.  For example, I didn't test any of the changes to the Linux specific code in FTLUnwindInfo.cpp.  See if failing tests work when the FTL is turned off.

One technique that I used to track down these kinds of problems was to add back in the saving and restoring of callee saves to the pushCalleeSaves() / popCalleeSaves() macros in LowLevelInterpreter.asm and then in LowLEvelInterpreter64.asm:doVMEntry, write sentinel numeric values to the callee saves registers, e.g. 0x1019 to x19, 0x1020 to x20, ... After &quot;makeCall()&quot; in doVMEntry and at the beginning of _handleUncaughtException, compare the values with a breakpoint on mismatch.  I made a macro to do the testing.  That did 2 things, first it allowed building with debug.  But probably more useful was that at any point executing in the JavaScript VMs I could look at the registers to see that they had the sentinel values were they should.  I could also check the CallFrames that we saved the sentinel values where appropriate.  I'll post a patch with this technique that I used for X86-64 debugging.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>