• Leszek Swirski's avatar
    Revert "V8 x64 backend doesn't emit ABI compliant stack frames" · 9f6ddb48
    Leszek Swirski authored
    This reverts commit 3cda21de.
    
    Reason for revert: Breaks the roll on Windows (see https://cr-buildbucket.appspot.com/build/8918477701097622400)
    
    Original change's description:
    > V8 x64 backend doesn't emit ABI compliant stack frames
    > 
    > On 64 bit Windows, the OS stack walking does not work because the V8 x64
    > backend doesn't emit unwinding info and also because it doesn't emit ABI
    > compliant stack frames. See
    > https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
    > for more details.
    > 
    > This problem can be fixed by observing that V8 frames usually all have the same
    > prolog and epilog:
    > 
    > push rbp,
    > mov rbp, rsp
    > ...
    > pop rbp
    > ret N
    > 
    > and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
    > should walk through V8 frames. Furthermore, since V8 Code objects are all
    > allocated in the same code-range for an Isolate, it is possible to register a
    > single PDATA/XDATA entry to cover stack walking for all the code generated
    > inside that code-range.
    > 
    > This PR contains changes required to enable stack walking on Win64:
    > 
    > EmbeddedFileWriter now adds assembler directives to the builtins
    > snapshot source file (embedded.cc) to emit additional entries in the .pdata and
    > in the .xdata section of the V8 executable. This takes care of stack walking
    > for embedded builtins. (The case of non-embedded builtins is not supported).
    > The x64 Assembler has been modified to collect the information required to emit
    > this unwind info for builtins.
    > 
    > Stack walking for jitted code is handled is Isolate.cpp, by registering
    > dynamically PDATA/XDATA for the whole code-range address space every time a new
    > Isolate is initialized, and by unregistering them when the Isolate is
    > destroyed.
    > 
    > Stack walking for WASM jitted code is handled is the same way in
    > wasm::NativeModule (wasm/wasm-code-manager.cpp).
    > 
    > It is important to note that Crashpad and Breakpad are already registering
    > PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
    > builtins). Since it is not possible to register multiple PDATA entries for the
    > same address range, a new function is added to the V8 API:
    > SetUnhandledExceptionCallback() can be used by an embedder to register its own
    > unhandled exception handler for exceptions that arise in v8-generated code.
    > V8 embedders should be modified accordingly (code for this is in a separate PR
    > in the Chromium repository:
    > https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
    > 
    > All these changes are experimental, behind:
    > 
    > the 'v8_win64_unwinding_info' build flag, and
    > the '--win64-unwinding-info' runtime flag.
    > 
    > Bug: v8:3598
    > Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
    > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
    > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
    > Cr-Commit-Position: refs/heads/master@{#60330}
    
    TBR=bbudge@chromium.org,ulan@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,gdeepti@chromium.org,jgruber@chromium.org,paolosev@microsoft.com
    
    Change-Id: If8470da94c58df8c800cbe8887f9f86236e43353
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Bug: v8:3598
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532321Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
    Commit-Queue: Leszek Swirski <leszeks@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#60372}
    9f6ddb48
assembler-x64.cc 119 KB