1. 08 Apr, 2020 1 commit
    • Clemens Backes's avatar
      Reland "[wasm] Debug in Liftoff by default" · 904a3e78
      Clemens Backes authored
      This is a reland of 44826509.
      TSan issue were fixed in https://crrev.com/c/2139574. One test
      failing in the 'stress' variant is skipped for now, until we figure
      out what the intended behaviour actually is.
      
      Original change's description:
      > [wasm] Debug in Liftoff by default
      >
      > This flips the --debug-in-liftoff flag to be on by default.
      > There are still some outstanding issues with that configuration, but not
      > more than with the interpreter configuration. Thus flip now, such that
      > we can fully focus on stabilizing that config.
      >
      > R=ecmziegler@chromium.org
      >
      > Bug: v8:10351
      > Change-Id: I7681f40aa2516557ef3ab4efd9a2c1f88e3b4df7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135727
      > Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67018}
      
      Bug: v8:10351, v8:10403
      Change-Id: I4c2f1af46233546d6ebeb638c7ef10aac56cd92d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139575
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67049}
      904a3e78
  2. 06 Apr, 2020 2 commits
  3. 26 Mar, 2020 1 commit
  4. 25 Mar, 2020 3 commits
  5. 24 Mar, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Fix OSR on wasm calls · 851a395f
      Clemens Backes authored
      This fixes issues with replacing the return address of deeper (non-top)
      wasm frames, i.e. frames which are at a call position. The replaced
      address should also point after the call in the new code, so we don't
      execute the same call again.
      
      This is achieved by using slightly different encodings for breakpoint
      positions and other (wasm instruction) positions. Breakpoints set
      {is_instruction} to {false} in the source position table entry, whereas
      usual wasm instruction set it to {true}.
      Also, during stack walking for OSR, we remember whether we want to OSR
      to the position before the instruction (if it's the top frame), or after
      the call instruction (if it's deeper in the stack). We then use the
      {is_instruction} predicate to find the right location.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10321
      Change-Id: I73212a7532c6ecf4c82bde76fe4059c8203e422c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116206Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66850}
      851a395f
  6. 19 Mar, 2020 1 commit
  7. 17 Mar, 2020 1 commit
  8. 13 Mar, 2020 2 commits
  9. 09 Jan, 2020 1 commit
  10. 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
  11. 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
  12. 15 Nov, 2019 1 commit
    • Eric Leese's avatar
      Report real module in addition to fake scripts · 6ec6ed9c
      Eric Leese authored
      Currently the inspector reports Wasm in one of two ways:
       - If there is a source map, report one script per Wasm script, with
         bytecode but no source.
       - If there is no source map, report one script per Wasm function, with
         source (Wasm disassembly) but no bytecode.
      
      With this change, behavior with source map is same, but without source
      map it will report both ways. This will allow us to change the frontend
      to do its own disassembly, allowing us to remove the per-function scripts
      in a future change.
      
      Bug: chromium:1013527
      Change-Id: I0c559ad08896e8d0da419e3c6ad8d1edff3976fc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1899782Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Eric Leese <leese@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64980}
      6ec6ed9c
  13. 08 Oct, 2019 1 commit
  14. 30 Jan, 2019 1 commit
  15. 13 Sep, 2018 1 commit