1. 28 Dec, 2020 1 commit
    • Benedikt Meurer's avatar
      [inspector][wasm] Remove obsolete Debugger.executeWasmEvaluator(). · 39645430
      Benedikt Meurer authored
      With https://crrev.com/c/2087396 we introduced a new CDP method
      `Debugger.executeWasmEvaluator()`, which we originally intended
      to use as the foundation for Debug-Evaluate on Wasm frames.
      
      However in the process of prototyping we learned that it is too
      costly and too inefficient to use WebAssembly modules here, and
      we switched to regular Debug-Evaluate with JavaScript instead
      (with a special debug proxy exposed that allows JavaScript to
      peak into the Wasm frame), since JavaScript is better suited
      for short-lived / short-running snippets and we don't need
      clang and wasm-ld then to generate these snippets.
      
      The JavaScript exposed debug proxy (as described in [1]) not
      only enables more powerful and flexible Debug-Evaluate for the
      DWARF C/C++ extension, but also serves as the basis for various
      aspects of the Basic Wasm Developer Experience.
      
      In order to pay down technical debt and to keep the maintenance
      overhead low, we should remove the initial prototype now, also
      to ensure that we don't accidentally attract other users of CDP
      to rely on this unsupported API (despite it being marked as
      "experimental").
      
      [1]: https://docs.google.com/document/d/1VZOJrU2VsqOZe3IUzbwQWQQSZwgGySsm5119Ust1gUA
      
      Fixed: chromium:1162062
      Bug: chromium:1020120, chromium:1068571, chromium:1127914
      Change-Id: I6dba8c906a8675ce6c29a52e3c32bb6626a27247
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605186
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71882}
      39645430
  2. 18 Oct, 2020 1 commit
    • Dmitry Gozman's avatar
      [inspector] Prepend isolateId to remoteObjectId · 66725a53
      Dmitry Gozman authored
      This changes remoteObjectId format from
      "{injectedScriptId:123,id:456}" to "<isolateId>.<contextId>.<id>".
      
      Prepending isolateId fixes the problem that
      remote object ids clash between processes. This is especially
      troubling during cross-process navigation in Chromium, see bug.
      
      We also stop producing and parsing unnecessary json for object ids.
      
      Drive-by: fixed some tests dumping object ids. Most tests avoid
      dumping unstable values like ids, but there were few that still did.
      
      BUG=chromium:1137143
      
      Change-Id: Ia019757fb95704ccb718d3ea6cc54bde1a133382
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461731
      Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70592}
      66725a53
  3. 13 Aug, 2020 1 commit
  4. 11 Aug, 2020 1 commit
  5. 04 Aug, 2020 1 commit
  6. 27 Jul, 2020 1 commit
  7. 16 Jul, 2020 1 commit
  8. 02 Jul, 2020 1 commit
  9. 26 Jun, 2020 1 commit
    • Benedikt Meurer's avatar
      [inspector] Set limit for Wasm wire byte transfer via CDP. · 7842920a
      Benedikt Meurer authored
      The `Debugger.getScriptSource()` and `Debugger.getWasmBytecode()`
      methods in the CDP return Wasm wire bytes as protocol::Binary, which is
      send as Base64-encoded JSON string in the communication to the DevTools
      front-end, and hence leads to either crashing the renderer that is being
      debugged or the renderer that's running the front-end if we allow
      arbitrarily huge Wasm byte sequences here. This CL introduces a limit,
      based on the maximum allowed string length, to avoid the crash and
      instead signal a proper error to the DevTools front-end.
      
      Bug: chromium:1099680
      Change-Id: I356d617301d17a4012f7f845773cf14e6ad1e4a7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270174
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68560}
      7842920a
  10. 19 Jun, 2020 1 commit
    • Kim-Anh Tran's avatar
      [wasm][debug] Keep breakpointIdToDebuggerBreakpointIds alive on reload · 09a5c855
      Kim-Anh Tran authored
      Until now the breakpointIdToDebuggerBreakpointIds was cleared on page
      reload. It keeps a map from breakpointIds to debuggerBreakpointIds,
      with the latter being necessary for removing breakpoints.
      
      If a breakpoint is set and we trigger a page reload, the
      information about that breakpoint will be removed from the map,
      even if it still exists. If we later want to remove the breakpoint
      we look into the map, but the meta data is no longer existing.
      
      Thus, reloading the page again will lead to hitting the breakpoint,
      even if we removed it in the front-end.
      
      This change keeps the map alive on page reset, so that we still
      keep track of set breakpoints after a page reload.
      
      Bug: chromium:1073071
      Change-Id: I82192777bac7afc406245a5a1cff0620e8174499
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253842Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68433}
      09a5c855
  11. 27 May, 2020 1 commit
    • Benedikt Meurer's avatar
      [inspector] Report length and endColumn correctly for Wasm. · 03ba73e4
      Benedikt Meurer authored
      Previously both the length and the endColumn for Wasm scripts were
      reported as 0, and that was sort of okayish, since the front-end
      was ignoring both of these fields in case of Wasm, and was applying
      special cases. But these special casing lead to some subtle bugs,
      and this is the first step towards a more uniform treatment.
      
      Source positions for Wasm are in terms of the bytecode, and the
      column field contains the bytecode offset here, while the line
      number field is always 0. Hence we send 0 for both startLine and
      endLine as before, but endColumn now corresponds to the bytecode
      size.
      
      Bug: chromium:1056632
      Change-Id: Ia8a9cfe454ed250b87a524f5cbcbbbe242205db6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215817
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67997}
      03ba73e4
  12. 05 May, 2020 2 commits
  13. 31 Mar, 2020 1 commit
  14. 26 Mar, 2020 1 commit
  15. 20 Mar, 2020 1 commit
  16. 17 Mar, 2020 1 commit
  17. 04 Feb, 2020 1 commit
  18. 03 Feb, 2020 1 commit
    • Sigurd Schneider's avatar
      [debugger] Allow termination-on-resume when paused at a breakpoint · 9e52d5c5
      Sigurd Schneider authored
      This CL implements functionality to allow an embedder to mark a
      debug scope as terminate-on-resume. This results in a termination
      exception when that debug scope is left and execution is resumed.
      Execution of JavaScript remains possible after a debug scope is
      marked as terminate-on-resume (but before execution of the paused
      code resumes).
      This is used by blink to correctly prevent resuming JavaScript
      execution upon reload while being paused at a breakpoint.
      
      This is important for handling reloads while paused at a breakpoint
      in blink. The resume command terminates blink's nested message loop
      that is used while to keep the frame responsive while the debugger
      is paused. But if a reload is triggered while execution is paused
      on a breakpoint, but before execution is actually resumed from the
       breakpoint (that means before returning into the V8 JavaScript
      frames that are paused on the stack below the C++ frames that belong
      to the nested message loop), we re-enter V8 to do tear-down actions
      of the old frame. In this case Runtime.terminateExecution() cannot be
      used before Debugger.resume(), because the tear-down actions that
      re-enter V8 would trigger the termination exception and crash the
      browser (because the browser expected the tear-down to succeed).
      
      Hence we introduce this flag on V8 that says: It is OK if someone
      re-enters V8 (to execute JS), but upon resuming from the breakpoint
      (i.e. returning to the paused frames that are on the stack below),
      generate a termination exception.
      
      We deliberated adding a corresponding logic on the blink side (instead
      of V8) but we think this is the simplest solution.
      
      More details in the design doc:
      
      https://docs.google.com/document/d/1aO9v0YhoKNqKleqfACGUpwrBUayLFGqktz9ltdgKHMk
      
      Bug: chromium:1004038, chromium:1014415
      
      Change-Id: I896692d4c21cb0acae89c1d783d37ce45b73c113
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924366
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66084}
      9e52d5c5
  19. 30 Jan, 2020 1 commit
  20. 09 Jan, 2020 1 commit
  21. 18 Dec, 2019 1 commit
  22. 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
  23. 08 Oct, 2019 1 commit
    • Ingvar Stepanyan's avatar
      [wasm] Pretend that DWARF section is a fake source map · 1b5f3be0
      Ingvar Stepanyan authored
      Unfortunately, codebase contains lots of places that use one of the two
      formats as an internal representation for Wasm locations:
      1) {line: 0, column: byte offset within entire module}
      2) {line: function index, column: byte offset within function}
      
      These places choose these formats interchangeably and convert from one
      to another depending on the presence of source map URL in Wasm.
      
      This is not very convenient and makes it hard to add support for DWARF
      which should behave just like Wasm with source maps - that is, report a
      raw Wasm script instead of fake scripts per each disassembled function,
      and use representation (1) instead of (2) internally.
      
      I tried to refactor these locations and avoid checking for source map
      URLs in the previous CL - https://crrev.com/c/v8/v8/+/1833688. However,
      it quickly got out of hand, and updating code in one place just kept
      revealing yet another that gets broken by the changes, so I made a
      decision to abandon it and leave to someone who knows the codebase
      better.
      
      Instead, this CL is based on https://crrev.com/c/v8/v8/+/1809375, but,
      rather than trying to integrate DWARF separately and only for supported
      agents, it pretends that encountering DWARF section is the same as
      encountering a `sourceMappingURL` section with fake URL "wasm://dwarf".
      
      This ensures that Wasm with DWARF behaves exactly in the same way as
      Wasm with source maps, just like we want, with minimal changes to the
      codebase. The only downside is that frontends without DWARF support
      won't get even a disassembled version of Wasm that contains DWARF info.
      This is unfortunate, but, as per previous discussions, should be fine
      given current state of Wasm debugging.
      
      Change-Id: Ia7256075e4bfd2f407d001d02b96883d7267436e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1834341
      Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64157}
      1b5f3be0
  24. 25 Sep, 2019 1 commit
    • Ingvar Stepanyan's avatar
      Add support for reporting raw Wasm scripts · c7848612
      Ingvar Stepanyan authored
      This addition will allow to experiment with parsing DWARF information from
      WebAssembly on the frontend side for improved debugging.
      
      The frontend must explicitly opt-in to this experiment by setting
      `supportsWasmDwarf: true` in `Debugger.enable` params.
      
      When this option is present, and Wasm appears to contain DWARF information
      (heuristic: `.debug_info` custom section is present), V8 will not try to
      disassemble and report each WebAssembly function as a separate fake script, but
      instead will report Wasm module as a whole.
      
      Note that V8 already does this when Wasm is associated with a source map.
      
      Additionally, this CL adds a dedicated `Debugger.getWasmBytecode` command that
      accepts scriptId and returns raw wire bytes of the chosen WebAssembly module.
      
      Change-Id: I7a6e80daf8d91ffaaba04fa15688f2ba9552870f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809375
      Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63969}
      c7848612
  25. 20 Sep, 2019 1 commit
  26. 13 Sep, 2019 1 commit
    • Dmitry Gozman's avatar
      [inspector] Simplify async stepping · fe3d51e1
      Dmitry Gozman authored
      Currently, debugger pauses on async call schedule and then waits for Debugger.pauseOnAsyncCall
      with parentStackTraceId to actually schedule the pause.
      
      This CL combines these two steps:
      - For local async tasks, it just stores m_taskWithScheduledBreak at the time of schedule,
        to be able to pause once this task is run.
      - For external async tasks, it plumbs "should_pause" boolean in V8StackTraceId from
        the point of schedule to the point of execution, and schedules a pause once
        externalAsyncTaskStarted is called with "should_pause" set to true.
      
      This approach greatly simplifies the implementation, and reduced frontend to a single
      "breakOnAsyncCall: true" parameter in Debugger.stepInto.
      
      Drive-by: introduce hasScheduledBreakOnNextFunctionCall() to make
      SetBreakOnNextFunctionCall management more robust.
      
      Note: artificial pauses at async call schedule time are gone from test expectations -
      we now only pause when user actually wants to pause, which makes protocol much simpler.
      
      See also design doc linked in the bug.
      
      BUG=chromium:1000475
      
      Change-Id: I2d16f79c599fe196b2aaeca8223c63437a2954a9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783724
      Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63737}
      fe3d51e1
  27. 10 Sep, 2019 1 commit
  28. 15 Jun, 2019 1 commit
  29. 10 May, 2019 1 commit
  30. 08 May, 2019 1 commit
  31. 16 Mar, 2019 1 commit
  32. 15 Mar, 2019 2 commits
  33. 14 Mar, 2019 2 commits
  34. 25 Feb, 2019 1 commit
  35. 30 Nov, 2018 1 commit
    • Yang Guo's avatar
      Make termination exception more consistent. · 7e5cac2c
      Yang Guo authored
      Termination exceptions tear down V8 to the bottom-most V8 call. If there is a
      v8::TryCatch scope around that call, it returns true for HasTerminated() and
      HasCaught(). However, Isolate::IsExecutionTerminating() returns false and we
      can call into V8 from still inside the v8::TryCatch scope.
      
      Changes that this patch introduces:
       - You need to leave the v8::TryCatch scope around the bottom-most call to
         reset the termination state, in order to resume.
       - Explicitly check for termination exception and reporting it through the
         DevTools protocol after Runtime.evaluate and Debugger.evaluateOnCallFrame.
      
      Bug: v8:8455
      Change-Id: I1f36f7a365985469813c2619bf16f18ee69aa4b8
      Reviewed-on: https://chromium-review.googlesource.com/c/1337582Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57963}
      7e5cac2c
  36. 29 Nov, 2018 1 commit
  37. 31 Oct, 2018 1 commit