<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#c5">Comment # 5</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:ossy@webkit.org" title="Csaba Osztrogonác <ossy@webkit.org>"> <span class="fn">Csaba Osztrogonác</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=149061#c3">comment #3</a>)
<span class="quote">> 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
> "makeCall()" 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.</span >
Thanks for the ideas and the patch for debugging.
I didn't check the FTL code yet, because it is disabled by default on Linux.
I don't know if it works at all, I didn't check it in the latest 4-5 months.
But it seems the bug is in the DFG tier somewhere, because tests pass with
(build time) disabled DFG. (except ~20 tests) And I already managed to catch
register mismatches with the idea you suggested. I'll continue debugging in
the near future.</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>