1. 02 Dec, 2021 1 commit
  2. 29 Nov, 2021 1 commit
  3. 24 Sep, 2021 1 commit
    • Clemens Backes's avatar
      [wasm][test] Cleanup macros · 156b2409
      Clemens Backes authored
      Some macros are redundant or unused.
      - WASM_RETURN1 is identical to WASM_RETURN.
      - WASM_RETURNN has an unused {count} parameter, and is otherwise
        identical to WASM_RETURN.
      - WASM_IFB is identical to WASM_IF.
      - WASM_CASE and WASM_CASE_BR are unused.
      - WASM_BR_TABLEV is unused.
      
      R=thibaudm@chromium.org
      
      Bug: v8:12244
      Change-Id: Ie7be00351f2dfe38d6e84d80e157a85df37233a9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178860Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77056}
      156b2409
  4. 01 Jun, 2021 1 commit
  5. 13 Apr, 2021 1 commit
  6. 05 Mar, 2021 1 commit
  7. 22 Feb, 2021 1 commit
  8. 17 Dec, 2020 1 commit
  9. 14 Sep, 2020 1 commit
    • Thibaud Michaud's avatar
      [wasm][debug] Fix DebugInfo deadlock · 383c4a44
      Thibaud Michaud authored
      Add a separate mutex for the {debug_side_tables_} field. This ensures
      that we can use {GetDebugSideTableIfExists} even if {mutex_} is already
      locked.
      
      R=ahaas@chromium.org
      CC=​​clemensb@chromium.org
      
      Bug: v8:10889
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Change-Id: Icb67c45aec0cf66814705b83532f4833f36738e1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402879
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69888}
      383c4a44
  10. 15 Jun, 2020 1 commit
  11. 26 May, 2020 1 commit
  12. 11 May, 2020 1 commit
  13. 08 May, 2020 1 commit
  14. 24 Apr, 2020 1 commit
  15. 27 Mar, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Stage --debug-in-liftoff behind --future · 0f4d68da
      Clemens Backes authored
      There are only three tests with differing behaviour if Liftoff is used
      for debugging.
      This CL thus stages the --debug-in-liftoff flag behind --future (tested
      by the "future" variant) and excludes the three tests.
      This allows us to test the other (already working) tests for
      regressions, and iteratively shrinking down the list of failing tests.
      
      Drive-by: Tier down modules in tests before testing debugging features
      to avoid hitting a DCHECK in Liftoff recompilation for debugging.
      
      R=thibaudm@chromium.org, ecmziegler@chromium.org
      
      Bug: v8:10351
      Change-Id: I3b1dd1a29258ecf13c1f60020fb06358005558d4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122021Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66889}
      0f4d68da
  16. 12 Mar, 2020 1 commit
  17. 21 Nov, 2019 1 commit
    • Clemens Backes's avatar
      Reland "[wasm] Prevent breakpoints on nonbreakable positions" · 5cf61684
      Clemens Backes authored
      This is an unmodified reland of 3c98a2a3.
      The actual issue was fixed in https://crrev.com/c/1926769.
      
      Original change's description:
      > [wasm] Prevent breakpoints on nonbreakable positions
      >
      > If a breakpoint is set on a non-breakable position, the wasm interpreter
      > just stores the value 0xFF (kInternalBreakpoint) in the function body
      > (actually, a copy of the function body). This might overwrite immediates
      > and cause subsequent failures in the wasm interpreter.
      >
      > In JavaScript, breakpoints are just forwarded to the next breakable
      > position. This CL implements the same for WebAssembly.
      > A cctest tests this behavior, and the existing
      > wasm-stepping-byte-offsets.js inspector test is extended to also set the
      > breakpoint within an i32 constant immediate.
      >
      > R=leese@chromium.org, mstarzinger@chromium.org
      > CC=​bmeurer@chromium.org
      >
      > Bug: chromium:1025184
      > Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65070}
      
      Bug: chromium:1025184
      Change-Id: I5e16df645bbacf039b7a5e55a0c2a64cdb4c6a32
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926152
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65093}
      5cf61684
  18. 20 Nov, 2019 2 commits
    • Clemens Backes's avatar
      Revert "[wasm] Prevent breakpoints on nonbreakable positions" · d1462a56
      Clemens Backes authored
      This reverts commit 3c98a2a3.
      
      Reason for revert: Fails on arm: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/12134
      
      Original change's description:
      > [wasm] Prevent breakpoints on nonbreakable positions
      > 
      > If a breakpoint is set on a non-breakable position, the wasm interpreter
      > just stores the value 0xFF (kInternalBreakpoint) in the function body
      > (actually, a copy of the function body). This might overwrite immediates
      > and cause subsequent failures in the wasm interpreter.
      > 
      > In JavaScript, breakpoints are just forwarded to the next breakable
      > position. This CL implements the same for WebAssembly.
      > A cctest tests this behavior, and the existing
      > wasm-stepping-byte-offsets.js inspector test is extended to also set the
      > breakpoint within an i32 constant immediate.
      > 
      > R=​leese@chromium.org, mstarzinger@chromium.org
      > CC=​​bmeurer@chromium.org
      > 
      > Bug: chromium:1025184
      > Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65070}
      
      TBR=mstarzinger@chromium.org,clemensb@chromium.org,bmeurer@chromium.org,leese@chromium.org
      
      Change-Id: I7468ea3b15fecccdea521308325cf4851e0a0396
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1025184
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926032Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65074}
      d1462a56
    • Clemens Backes's avatar
      [wasm] Prevent breakpoints on nonbreakable positions · 3c98a2a3
      Clemens Backes authored
      If a breakpoint is set on a non-breakable position, the wasm interpreter
      just stores the value 0xFF (kInternalBreakpoint) in the function body
      (actually, a copy of the function body). This might overwrite immediates
      and cause subsequent failures in the wasm interpreter.
      
      In JavaScript, breakpoints are just forwarded to the next breakable
      position. This CL implements the same for WebAssembly.
      A cctest tests this behavior, and the existing
      wasm-stepping-byte-offsets.js inspector test is extended to also set the
      breakpoint within an i32 constant immediate.
      
      R=leese@chromium.org, mstarzinger@chromium.org
      CC=​bmeurer@chromium.org
      
      Bug: chromium:1025184
      Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65070}
      3c98a2a3
  19. 05 Nov, 2019 1 commit
    • Eric Leese's avatar
      V8 Wasm locations should always be based on byte offsets · 5c23e6b5
      Eric Leese authored
      Currently there are two ways wasm locations are represented in the
      inspector. This remains unchanged for now. Also, currently there are
      multiple ways location is represented within V8, with the line number
      sometimes being a function index and sometimes being 0, and the column
      number being a byte offset which is sometimes function relative and
      sometimes module relative. With this change, the line number is never
      used within V8 (it is always 0), and the column number is always a
      byte offset from the beginning of the module. This simplifies
      translation logic and keeps it in one place, and will simplify future
      changes to wasm location representation in the inspector API.
      
      Bug: chromium:1013527
      Change-Id: I8813d47c881988f9ab49d7529fb81fe10dbbccff
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886915
      Commit-Queue: Eric Leese <leese@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64774}
      5c23e6b5
  20. 16 Oct, 2019 1 commit
  21. 10 Oct, 2019 1 commit
  22. 08 Oct, 2019 2 commits
  23. 10 Sep, 2019 1 commit
  24. 08 Jul, 2019 1 commit
  25. 23 May, 2019 2 commits
  26. 22 May, 2019 1 commit
  27. 21 May, 2019 1 commit
  28. 20 May, 2019 1 commit
  29. 08 Dec, 2018 1 commit
  30. 17 Sep, 2018 1 commit
  31. 21 Aug, 2018 1 commit
  32. 27 Jun, 2018 1 commit
  33. 23 Jun, 2018 1 commit
  34. 13 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Merge {WasmSharedModuleData} with {WasmModuleObject} · b9b4b879
      Clemens Hammacher authored
      The {WasmSharedModuleData} struct was introduced to hold data common to
      all wasm instances belonging to the same module. The idea was to keep
      "internal state" separate from the JS-facing {WasmModuleObject}. Since
      this objective has no real value, and we already store some internal
      data on the {WasmModuleObject}, this CL merges these two objects.
      
      R=titzer@chromium.org, mstarzinger@chromium.org
      
      Bug: v8:7754
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I04f6d07bf5d812bc4717af26f0f64231345861f9
      Reviewed-on: https://chromium-review.googlesource.com/1097491
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53698}
      b9b4b879
  35. 03 Jun, 2018 1 commit
  36. 14 May, 2018 1 commit
  37. 07 May, 2018 1 commit