[Webkit-unassigned] [Bug 190656] useProbeOSRExit causes failures for Win64 DFG JIT

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=190656

Ross Kirsling <ross.kirsling at sony.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |keith_miller at apple.com,
                   |                            |mark.lam at apple.com,
                   |                            |sbarati at apple.com,
                   |                            |stephan.szabo at sony.com,
                   |                            |yusukesuzuki at slowstart.org

--- Comment #1 from Ross Kirsling <ross.kirsling at sony.com> ---
I'll try to list up what I know so far:

- FWIW, testmasm has no failures on WinCairo.

- If I dataLog on save and restore in DFGOSREntry.cpp, AssemblyHelpers.h, and DFGOSRExit.cpp (and use printEachOSRExit), it definitely looks like callee-save registers are saved and restored consistently whether or not the probe is used.

- If I use dumpDFGDisassembly and blot out all raw hex values (and normalize Structure identifiers), then the output is consistent with or without the probe. There is a final large codeblock which is only spit out in the non-probe case, but that's also true on Mac, which isn't broken.

- On the last run of operationPutGetterSetter (in JITOperations.cpp), the encodedGetterValue has an entirely different prefix (0x00007FFB... instead of 0x000001...) from the first 2305 times. If we look at the JSCell for the getter, there is one point of potential note...

  All cases without probe, first 2305 cases with probe:
    m_structureID             0x00000104                      unsigned int
    m_indexingTypeAndMisc     0x00 '\0'                       unsigned char
    m_type                    JSFunctionType (0x18 '\x18')    JSC::JSType
    m_flags                   0x0e '\xe'                      unsigned char
    m_cellState               DefinitelyWhite (0x01 '\x1')    JSC::CellState

  Final case, after DFG OSR exit, with probe:
    m_structureID             0x0000000d                      unsigned int
    m_indexingTypeAndMisc     0x18 '\x18'                     unsigned char
    m_type                    CellType (0x00 '\0')            JSC::JSType
    m_flags                   0x00 '\0'                       unsigned char
    m_cellState               PossiblyBlack (0x00 '\0')       JSC::CellState

...namely, that 0x18 seems like it's jumped up a slot. But then, everything after it is zeroes, so this may be a red herring...?

- One way or another, it's hard to imagine what other than Win64 calling convention could be at play here. Now, although we're saving and restoring RBX, RSI, RDI, R12, R13, R14, and R15, we're intentionally skipping over RBP and RSP -- RBP appears to be callee-save for x86_64 in general, so surely that one's a non-issue(?), but RSP is callee-save for Windows (according to MSDN, although it's not indicated as such in RegisterSet or GPRInfo) so perhaps the probe mucks with the stack pointer in a way that Win64 doesn't like?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181019/1cdf525a/attachment.html>