1. 22 Jan, 2020 1 commit
  2. 16 Jan, 2020 1 commit
    • Jakob Gruber's avatar
      [compiler] Consider pushed arguments in stack check offset · 2cd24eba
      Jakob Gruber authored
      Function calls can push arguments onto the stack. The consumed stack
      slots are not considered by the function-entry stack check, since
      initial frame setup only reserves space for local slots, not call
      arguments. This CL adds such logic by tracking the maximum pushed
      argument count during instruction selection, and adding these slots to
      the (existing) stack check offset logic in code generation.
      
      Bug: chromium:1030167
      Change-Id: I26a9407cf38009839b1dda2ff0c8ec297c15ed8d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002540
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65814}
      2cd24eba
  3. 28 Nov, 2019 1 commit
    • Michael Starzinger's avatar
      [wasm] Remove obsolete {Builtins::IsWasmRuntimeStub}. · 5d272cf8
      Michael Starzinger authored
      The last use of the predicate in question was to switch builtins that
      implement WebAssembly runtime stubs to use hard aborts instead of normal
      aborts like other builtins. This is no longer needed since the builtins
      in question are embedded and no longer copied into WebAssembly modules.
      
      This also allows to move the {WASM_RUNTIME_STUB_LIST} macro out of the
      builtins-defintions.h file and into the wasm-code-manager.h file.
      
      R=clemensb@chromium.org
      BUG=v8:10021
      
      Change-Id: Ib42d3731fc92df378cfce39d39e7fbdbbf722937
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1940266
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65238}
      5d272cf8
  4. 19 Nov, 2019 1 commit
    • Jakob Gruber's avatar
      [compiler] Allow deopts to slightly exceed the stack limit · 4547c5ef
      Jakob Gruber authored
      We recently extended function-entry stack checks by an offset
      representing the difference in optimized and unoptimized frame sizes,
      with the intent of avoiding stack overflows during deopts. Although
      the generated code is very efficient (just a single additional
      register subtraction, executed exactly once per call), perf impact
      is measurable.
      
      To avoid the overhead in most cases, this CL adds a stack slack,
      currently set to 256 bytes, by which deopts are allowed to exceed the
      real V8 stack limit. For function-entry stack checks with an offset
      less than stack slack, the offset is not applied and the more
      efficient version of the stack check is emitted.
      
      The V8 limit is chosen to be smaller than OS stack size (assumed to
      be at least 1 MB). This guarantee is upheld even with slack.
      
      Bug: chromium:1020989,v8:9534
      Change-Id: Idee2e7ad1fa7810bf086a9f72ce00a9717010310
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910099Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65025}
      4547c5ef
  5. 15 Nov, 2019 1 commit
  6. 07 Nov, 2019 1 commit
  7. 31 Oct, 2019 1 commit
  8. 30 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      Reland "[compiler] Optionally apply an offset to stack checks" · b875f466
      Jakob Gruber authored
      This is a reland of 4a16305b
      
      The original CL adjust only one part of the stack check, namely the
      comparison of the stack pointer against the stack limit in generated code.
      There is a second part: Runtime::kStackGuard repeats this check to
      distinguish between a stack overflow and an interrupt request.
      
      This second part in runtime must apply the offset just like in generated
      code. It is implemented in this reland by the StackCheckOffset operator
      and a new StackGuardWithGap runtime function.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      >
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      >
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      >
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      >
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      >
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      Bug: v8:9534, chromium:1000887
      Change-Id: I71771c281afd7d57c09aa48ea1b182d01e6dee2a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822037Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64634}
      b875f466
  9. 12 Sep, 2019 3 commits
    • Jakob Gruber's avatar
      Revert "[compiler] Optionally apply an offset to stack checks" · ba72dc08
      Jakob Gruber authored
      This reverts commit 4a16305b.
      
      Reason for revert: Need to revalidate assumptions behind the CHECK.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      > 
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      > 
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      > 
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      > 
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      > 
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org
      
      Change-Id: Iebf46d5256b6dee13451741781ef85a5fe9b1628
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9534, chromium:1000887
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800565Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63706}
      ba72dc08
    • Clemens Hammacher's avatar
      [base] Implement {Reversed} using {rbegin} and {rend} · 98c86c6b
      Clemens Hammacher authored
      This removes the {base::ReversedAdapter} class and uses
      {base::iterator_range} instead. The types are inferred from what
      {std::rbegin} and {std::rend} return.
      
      Since src/base/adapters.h would only contain this one method after
      this refactoring, it was merged into src/base/iterator.h.
      Some includes of src/base/adapters.h were unused and hence dropped.
      
      R=mlippautz@chromium.org
      
      Bug: v8:9396
      Change-Id: I597172ec790193b73af196d1afcd64bbed0a597d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1798432Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63703}
      98c86c6b
    • Jakob Gruber's avatar
      [compiler] Optionally apply an offset to stack checks · 4a16305b
      Jakob Gruber authored
      The motivation behind this change is that the frame size of an optimized
      function and its unoptimized version may differ, and deoptimization
      may thus trigger a stack overflow. The solution implemented in this CL
      is to optionally apply an offset to the stack check s.t. the check
      becomes 'sp - offset > limit'. The offset is applied to stack checks at
      function-entry, and is set to the difference between the optimized and
      unoptimized frame size.
      
      A caveat: OSR may not be fully handled by this fix since we've already
      passed the function-entry stack check. A possible solution would be to
      *not* skip creation of function-entry stack checks for inlinees.
      
      This CL: 1. annotates stack check nodes with the stack check kind, where
      kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      allocates a temporary register to store the result of the 'sp - offset'
      in instruction selection (and switches input registers to 'unique'
      mode). 3. Applies the offset in code generation.
      
      Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      
      Bug: v8:9534,chromium:1000887
      Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63701}
      4a16305b
  10. 29 Aug, 2019 1 commit
  11. 26 Aug, 2019 1 commit
  12. 23 Aug, 2019 3 commits
  13. 06 Aug, 2019 1 commit
    • Jakob Gruber's avatar
      Move knowledge of frame stack height into the FrameStateDescriptor · 9b24f6ec
      Jakob Gruber authored
      When serializing frame states into translations (later used by
      deopts), we pass certain values, depending on the frame kind, to be
      serialized as the frame height.
      
      This CL moves the calculation of this height value into the
      FrameStateDescriptor. In a follow-up, we may want to simplify the way
      these height values are passed and processed by deopts.
      
      The motivation behind this is to simplify calculation of unoptimized
      stack frame sizes during compilation.
      
      Bug: v8:9534
      Change-Id: I20d2b57a42cea0c238b9c887dba0280f6aad76de
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728609
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63085}
      9b24f6ec
  14. 31 Jul, 2019 1 commit
    • Tom Tan's avatar
      Unwind V8 frames correctly on Windows ARM64 · 3f1f001a
      Tom Tan authored
      On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend
      doesn't emit unwinding info and also because it doesn't emit ABI compliant
      stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and
      documented below:
      
      https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0
      
      This problem can be fixed similarly for Windows ARM64 by observing that V8
      frames usually all have the same prolog which maintains a chain via frame
      pointer (fp or x29 register).
      
      stp fp, lr, [sp, ...]
      
      One exception is JSEntry which stops fp pointer chain and needs to be handled
      specially.
      
      So it is possible to define XDATA with UNWIND_CODE which specify how Windows
      should walk through V8 dynamic frames. The same as X64, since V8 Code objects
      are all allocated in the same code-range for an Isolate, it is possible to
      register at most 2 XDATA and a group of PDATA entries to cover stack walking
      for all the code generated inside that code-range. This is more than 1
      PDATA/XDATA because according to the Windows ARM64 exeption handling document,
      1 PDATA can cover less than 1MB code range (see below doc).
      
      https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling
      
      This PR implements stackwalk for Windows ARM64 to be on par with X64, including
      embedded builtins, jitted code and wasm jitted code, but not including register
      handler for handling exception only, because there is no backward compatibility
      to maintain for Windows ARM64 which was released since 1709 windows build.
      
      Bug: chromium:893460
      Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63002}
      3f1f001a
  15. 30 Jul, 2019 2 commits
  16. 25 Jul, 2019 2 commits
  17. 31 May, 2019 1 commit
    • Santiago Aboy Solanes's avatar
      [ptr-compr][turbofan][CSA] Adding the CompressedHeapConstant node · a31b36e0
      Santiago Aboy Solanes authored
      CompressedHeapConstant is used in the DecompressionElimination Reducer to
      create compressed HeapConstant values. It won't appear in the graph
      up until that point.
      
      This CL enables back the disabled tests in DecompressionElimination, as
      well as generating the CompressedHeapConstant in that reducer.
      
      The RelocInfo has already been added for x64 but not for arm64. Therefore,
      the x64 version is now doing the mov on 32 bits. The support for ARM will
      come in a following CL, and for now it is doing the mov in 64 bits.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
      Bug: v8:8977, v8:7703, v8:9298
      Change-Id: If0ca4f937cfa60501679e66f6fd5ded2df38f605
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632236Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61950}
      a31b36e0
  18. 24 May, 2019 1 commit
  19. 23 May, 2019 2 commits
  20. 22 May, 2019 1 commit
  21. 21 May, 2019 1 commit
  22. 20 May, 2019 1 commit
  23. 17 May, 2019 2 commits
  24. 10 May, 2019 1 commit
  25. 08 May, 2019 1 commit
  26. 29 Apr, 2019 1 commit
  27. 18 Apr, 2019 1 commit
  28. 03 Apr, 2019 1 commit
    • Paolo Severini's avatar
      Reland "V8 x64 backend doesn't emit ABI compliant stack frames" · 969cb0c7
      Paolo Severini authored
      This is a reland of 3cda21de
      
      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}
      
      Bug: v8:3598
      Change-Id: If988baf7d3e4af165b919d6e54c1ad985f8e25e3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1534618Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#60581}
      969cb0c7
  29. 25 Mar, 2019 1 commit
  30. 20 Mar, 2019 1 commit
    • 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
  31. 19 Mar, 2019 1 commit
    • Paolo Severini's avatar
      V8 x64 backend doesn't emit ABI compliant stack frames · 3cda21de
      Paolo Severini authored
      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/+/1469329Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#60330}
      3cda21de
  32. 12 Mar, 2019 1 commit