Skip to content

V
V8
Switch branch/tag
  1. 28 Oct, 2019 1 commit
  3. 13 Sep, 2019 1 commit
  5. 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
  7. 27 May, 2019 2 commits
  9. 24 May, 2019 1 commit
  11. 22 May, 2019 3 commits
  13. 21 May, 2019 1 commit
  15. 20 May, 2019 1 commit
  17. 17 May, 2019 2 commits
  19. 15 May, 2019 1 commit
  21. 24 Apr, 2019 1 commit
  23. 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
  25. 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
  27. 19 Mar, 2019 2 commits
    • Milad Farazmand's avatar
      PPC: adding torque debug info for AIX on PPC · a353f453
      Milad Farazmand authored 
      Due to ppc having a fixed 4 byte instruction length, changing
ByteChunk length from 8 to 4 bytes will fix any padding issues
while generating the "embed.S" file.

Change-Id: Ide799908effd88d5387e97627917b095fcc3051c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524720
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60337}
      a353f453
    • 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
  29. 18 Feb, 2019 1 commit
    • Mike Stanton's avatar
      Reland "[Torque] Add source positions for Torque files" · b08c6947
      Mike Stanton authored 
      Reason for revert/reland: UBSan complained of unaligned reads.

To improve the Torque debugging experience, we can add source positions
for each line. This information is carried through the generated
CSA code (in <output directory>/gen/torque-generated/*.cc) and
embedded as SourcePositions in the Code object.

At snapshot time, these SourcePositions are stripped from the Code
object and turned into platform-appropriate line number debug
information.

At this time on Linux, you'll need to build with "is_clang=false"
in order to use GCC, because crucial steps are missing in Clang's
ability to convey the information into the binary successfully.

This CL also introduces a flag to control the existing source
information in CSA code. --enable-source-at-csa-bind is now set
to false by default because it's a bit confusing to "hop" between
source lines in .TQ files and in .CC files. I expect to continue
making adjustments there, as I want to provide helpful
debugging aids at the CSA level as well as the Torque level.
The current configuration prioritizes Torque.

TBR=tebbi@chromium.org

Bug: v8:8418
Change-Id: Idb80467d3679ec2361386fe9b67597b93d7f72cf
Reviewed-on: https://chromium-review.googlesource.com/c/1475763Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59657}
      b08c6947
  31. 24 Jan, 2019 1 commit
  33. 22 Jan, 2019 1 commit
    • Mike Stanton's avatar
      [Builtins] Infrastructure for source positions in stubs/builtins · df071e94
      Mike Stanton authored 
      Now, the CodeAssembler can annotate Nodes with SourcePositions.
SourcePositions themselves get a new mode "external," in which
they get a file_id, line and column. The file_id is currently
maintained in the isolate, mapping to strings for filenames.

Additionally, inlining information is ignored at this point,
but in the long run I'd like to recognize calls to different
CSA functions as manual inlinings.

At this point, if you want to see the results in tools like GDB,
you'll need to build without clang, and use the GCC toolchain.
GN flag is_clang=false will do the trick.

Bug: v8:8418
Change-Id: I123cdc041612285fa7d0ba532a625bceeda5d338
Reviewed-on: https://chromium-review.googlesource.com/c/1322954
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59009}
      df071e94
  35. 28 Nov, 2018 2 commits
  37. 22 Nov, 2018 1 commit
  39. 19 Nov, 2018 1 commit
    • Jakob Gruber's avatar
      [builtins] Reduce the generated embedded.S file size on windows · 4ca93a64
      Jakob Gruber authored 
      Windows MASM becomes extremely slow when given very large data streams.
Runtime behavior is super-linear, with compile times of

  5s for 50 KLOC in embedded.S
 15s for 100KLOC
 40s for 150KLOC

Compilation of the 320KLOC file produced for debug builds took more than
5 minutes.

This CL reduces compile time by emitting QWORD directives instead,
which reduces the emitted debug embedded.S to around 120KLOC and
compile times to around 40s.

Bug: v8:8475,v8:6666
Change-Id: I19903cdf7d1b70a65c00ca67f40129847b17f386
Reviewed-on: https://chromium-review.googlesource.com/c/1341951Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57609}
      4ca93a64
  41. 15 Nov, 2018 3 commits