1. 17 Apr, 2019 1 commit
  2. 10 Apr, 2019 1 commit
    • Paolo Severini's avatar
      Fix build error on ARM64/Windows · 97562879
      Paolo Severini authored
      In file include/v8config.h we define:
      
      ifdef V8_OS_WIN
      ...
      if defined(_M_X64) || defined(__x86_64__)
        define V8_OS_WIN_X64 true
      endif
      
      and V8_OS_WIN_X64 is supposed to be defined when targeting X64 on Windows only.
      But this is wrong because V8_OS_WIN_X64 gets defined also on an ARM64 builds
      when the host machine is X64. It should instead be:
      
      ifdef V8_OS_WIN
      ...
      if defined(V8_TARGET_ARCH_X64)
        define V8_OS_WIN_X64 true
      endif
      
      Bug: v8:9090
      Change-Id: I88e4c46bb6df1efa2070d4e1785081d71df96f0e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554222Reviewed-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@{#60758}
      97562879
  3. 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
  4. 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
  5. 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
  6. 17 Dec, 2018 2 commits
  7. 05 Nov, 2018 1 commit
  8. 07 Sep, 2018 1 commit
  9. 18 Jul, 2018 1 commit
    • Dan Elphick's avatar
      Fix uses of V8_DEPRECATE_SOON in v8.h · ed9ea216
      Dan Elphick authored
      Move brackets enclosing declarator in a couple of V8_DEPRECATE_SOON
      cases so that the attribute is correctly placed.
      
      I.e. should come after the class keyword and after a function signature
      but before the body.
      
      Also adds suppressions for a case where a replacement method calls
      the deprecated method it replaces.
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I490ff07a13552cf335186d64ca061f21ac4e8afc
      Reviewed-on: https://chromium-review.googlesource.com/1140593Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54527}
      ed9ea216
  10. 25 Apr, 2018 1 commit
  11. 06 Apr, 2018 1 commit
  12. 26 Jun, 2017 1 commit
  13. 13 Jun, 2017 1 commit
  14. 11 Jun, 2017 1 commit
    • scottmg's avatar
      Basic compilation on Fuchsia · c72a6126
      scottmg authored
      Sufficient to compile //v8 in Chrome with target_os="fuchsia". Doesn't
      link yet, due to missing implementations (primarily VirtualMemory, as
      well as a few utility functions).
      
      BUG=chromium:731217
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2931143002
      Cr-Commit-Position: refs/heads/master@{#45831}
      c72a6126
  15. 15 May, 2017 1 commit
  16. 27 Jul, 2016 1 commit
  17. 22 Mar, 2016 1 commit
  18. 25 Nov, 2015 1 commit
  19. 08 Oct, 2015 2 commits
  20. 07 Oct, 2015 1 commit
  21. 05 Oct, 2015 2 commits
  22. 28 Sep, 2015 2 commits
  23. 29 Jun, 2015 1 commit
  24. 12 Jun, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Use appropriate type for NodeId. · c487aba7
      bmeurer authored
      Up until now we used int32_t for NodeId, but that was not ideal because
      negative values are invalid for NodeId and we use it as an array index
      for example in the NodeMarker class, where C++ compilers on x64 have to
      generate code that does proper sign extension for the indices, which is
      completely unnecessary.
      
      R=svenpanne@chromium.org
      
      Review URL: https://codereview.chromium.org/1178403004
      
      Cr-Commit-Position: refs/heads/master@{#28997}
      c487aba7
  25. 21 May, 2015 2 commits
  26. 05 May, 2015 1 commit
  27. 20 Apr, 2015 1 commit
  28. 14 Apr, 2015 1 commit
  29. 25 Mar, 2015 1 commit
  30. 09 Mar, 2015 1 commit
  31. 27 Feb, 2015 1 commit
  32. 30 Jan, 2015 2 commits
  33. 02 Dec, 2014 1 commit
    • thakis's avatar
      Set V8_CC_GNU or V8_CC_MSVC for clang in gcc / cl mode. · 643c24eb
      thakis authored
      Also, remove V8_CC_CLANG since it's not read anywhere (and ideally shouldn't
      be).
      
      Clang tries to be compatible with gcc in clang mode, and with msvc in clang-cl
      mode. It wants to go down the same code paths that these compilers want to go
      down in most cases.
      
      For example, V8PRIxPTR was set incorrectly on Windows 64-bit before this change
      since macros.h assumed that checking for V8_CC_MSVC is enough to find LLP64
      systems, but V8_CC_MSVC wasn't set for clang.  Most other existing checks for
      V8_CC_MSVC should be taken for clang-cl too (and for the remaining ones,
      clang-cl is happy with either code path).
      
      Likewise, V8_IMMEDIATE_CRASH is currently set to a suboptimal value with clang
      since __builtin_trap() is only used if V8_CC_GNU is set.
      
      Including clang in the gcc and cl macros is also what chromium does.
      
      BUG=chromium:82385
      LOG=y
      
      Review URL: https://codereview.chromium.org/757553004
      
      Cr-Commit-Position: refs/heads/master@{#25592}
      643c24eb
  34. 22 Oct, 2014 1 commit