1. 19 Jul, 2022 2 commits
  2. 15 Jun, 2022 1 commit
    • Simon Zünd's avatar
      Reland "[inspector] Allow Debugger.setScriptSource to edit top-most function" · 21fe5e0f
      Simon Zünd authored
      This is a reland of commit dac61556
      
      This is a straight-up reland with no changes, because:
        1) The failure doesn't reproduce locally
        2) The failing flaky test that triggered the revert is not related
           to the code modified by this CL and should (in theory) not be
           impacted.
      
      Original change's description:
      > [inspector] Allow Debugger.setScriptSource to edit top-most function
      >
      > This CL adds a new boolean flag on the Debugger.setScriptSource CDP
      > method that gets piped all the way through to the live-edit mechanism.
      > The new flag enables live-editing of the top-most function while
      > paused.
      >
      > The CL adds a couple of tests that cover the new core use cases for
      > this flag.
      >
      > R=jarin@chromium.org
      >
      > Bug: chromium:1334484
      > Change-Id: I12fec591b2b6550d89748714620e629548e1b9c1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695354
      > Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#81127}
      
      Bug: chromium:1334484
      Change-Id: I9a9bf7e03d81c86adb4819b9756dd9afcf6fa021
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3706398Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81171}
      21fe5e0f
  3. 14 Jun, 2022 2 commits
  4. 09 Jun, 2022 1 commit
    • Simon Zünd's avatar
      [inspector] Introduce status result for Debugger.setScriptSource · 31850be1
      Simon Zünd authored
      This CL introduces a new `status` enum returned by setScriptSource.
      We'll use the information in the DevTools frontend to show more
      meaningful error messages as well as disambiguate compilation errors
      from failed live edits.
      
      Drive-by: Deprecate the sync and async stack traces in the result.
      Currently `setScriptSource` is guaranteed to stay paused so there
      is no need to send along the same information from the
      preceeding `Debugger.paused` event.
      In the future we will restart the top-most frame once we allow
      the top-most frame to be edited. In that case the inspector
      fires Debugger.resumed + Debugger.paused events following the
      live edit also making the info returned here superfluous.
      
      R=jarin@chromium.org
      
      Bug: chromium:1334484
      Change-Id: I4226491caed72013a00927273c523213d797a766
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3691850
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81031}
      31850be1
  5. 14 May, 2022 1 commit
    • Simon Zünd's avatar
      Reland "[inspector] Re-enable Debugger#restartFrame" · 9ca7491b
      Simon Zünd authored
      This is a reland of commit 8278cb50
      
      The reland adds the RestartFrameTrampoline to the list of
      builtins that the deoptimizer is allowed to return from for
      control flow integrity.
      
      Original change's description:
      > [inspector] Re-enable Debugger#restartFrame
      >
      > Doc: https://bit.ly/revive-restart-frame
      >
      > This CL "undeprecates" Debugger#restartFrame and adds a new optional
      > "mode" parameter for back-wards compatibility. Moreover, the return
      > values are all deprecated. They were never actually used in the
      > DevTools frontend and the same information is available from the
      > Debugger#paused event that fires once execution stops at the
      > beginning of the restarted function.
      >
      > The CL also re-baselines all the restart-frame inspector tests that
      > now run successfully.
      >
      > R=bmeurer@chromium.org, kimanh@chromium.org
      >
      > Bug: chromium:1303521
      > Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80491}
      
      Bug: chromium:1303521
      Change-Id: I13e2f8b5011795a38e541310622b8333a3d08049
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644624Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80534}
      9ca7491b
  6. 12 May, 2022 2 commits
  7. 23 Feb, 2022 1 commit
  8. 22 Feb, 2022 1 commit
  9. 11 Feb, 2022 1 commit
  10. 02 Dec, 2021 1 commit
  11. 29 Nov, 2021 1 commit
  12. 27 May, 2021 1 commit
  13. 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
  14. 18 Nov, 2020 1 commit
  15. 11 Aug, 2020 1 commit
  16. 04 Aug, 2020 1 commit
  17. 05 May, 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. 18 Dec, 2019 1 commit
  20. 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
  21. 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
  22. 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
  23. 13 Sep, 2019 2 commits
    • Clemens Hammacher's avatar
      [iwyu] Add missing includes of <memory> for std::unique_ptr · 75790c98
      Clemens Hammacher authored
      After https://crrev.com/c/1800575 and https://crrev.com/c/1803343,
      which tried to fix this on occuring compile errors, this CL
      systematically adds the <memory> include to each header that uses
      {std::unique_ptr}.
      
      R=sigurds@chromium.org
      TBR=mlippautz@chromium.org,alph@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org
      
      Bug: v8:9396
      Change-Id: If7f9c3140842f9543135dddd7344c0f357999da0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803349Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63767}
      75790c98
    • 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
  24. 08 May, 2019 1 commit
  25. 16 Mar, 2019 1 commit
  26. 15 Mar, 2019 2 commits
  27. 14 Mar, 2019 2 commits
  28. 29 Nov, 2018 1 commit
  29. 28 Sep, 2018 1 commit
  30. 13 Jul, 2018 1 commit
  31. 26 Apr, 2018 2 commits
  32. 25 Apr, 2018 1 commit
  33. 23 Apr, 2018 1 commit