1. 23 Feb, 2022 1 commit
  2. 22 Feb, 2022 1 commit
  3. 11 Feb, 2022 1 commit
  4. 02 Dec, 2021 1 commit
  5. 29 Nov, 2021 1 commit
  6. 27 May, 2021 1 commit
  7. 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
  8. 18 Nov, 2020 1 commit
  9. 11 Aug, 2020 1 commit
  10. 04 Aug, 2020 1 commit
  11. 05 May, 2020 1 commit
  12. 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
  13. 18 Dec, 2019 1 commit
  14. 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
  15. 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
  16. 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
  17. 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
  18. 08 May, 2019 1 commit
  19. 16 Mar, 2019 1 commit
  20. 15 Mar, 2019 2 commits
  21. 14 Mar, 2019 2 commits
  22. 29 Nov, 2018 1 commit
  23. 28 Sep, 2018 1 commit
  24. 13 Jul, 2018 1 commit
  25. 26 Apr, 2018 2 commits
  26. 25 Apr, 2018 1 commit
  27. 23 Apr, 2018 1 commit
  28. 22 Mar, 2018 1 commit
  29. 16 Feb, 2018 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] cleanup old failed to parse anonymous scripts · 6db8a9c0
      Alexey Kozyatinskiy authored
      We already cleanup these scripts on frontend side. It is crucial to
      cleanup them on backend side as well, since some web applications use
      following logic: get some data from network, add this data to buffer,
      try to parse buffer using JSON.parse. On each unsuccessfull JSON.parse
      we get another scriptFailedToParse event.
      
      Frontend logic of discarding scripts: https://goo.gl/FDtaWK
      
      Some idea of smarter logic here: track what script ids are reported
      using protocol and cleanup only script ids which reported not only as
      part of scriptFailedToParse event.
      
      R=alph@chromium.org
      
      Bug: chromium:810812
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Ifd67764c232e4abc7dc6e8e69a651bf9ac0e381b
      Reviewed-on: https://chromium-review.googlesource.com/919834
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAlexei Filippov <alph@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51337}
      6db8a9c0
  30. 02 Feb, 2018 1 commit
  31. 29 Nov, 2017 1 commit
  32. 23 Nov, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] introduced universal Debugger.pauseOnAsyncCall · 653a9e2b
      Alexey Kozyatinskiy authored
      If protocol client needs to make step-into async call:
      - pause before async call using any Debugger agent capabilities,
      - call Debugger.stepInto with breakOnAsyncCall flag,
      - wait for Debugger.paused event, this event will contain
        asyncCallStackTrace if async call is scheduled,
      - call Debugger.pauseOnAsyncCall on each known target,
      - resume execution in current debugger by Debugger.resume.
      
      Bug: chromium:778796
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I40c56278e7b1ceafc3bf81608b8ca6716c2b3168
      Reviewed-on: https://chromium-review.googlesource.com/773573
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49594}
      653a9e2b
  33. 22 Nov, 2017 3 commits
    • Alexey Kozyatinskiy's avatar
      Reland [inspector] introduced stackTraceId and externalAsyncTask API · 885a5669
      Alexey Kozyatinskiy authored
      Sometimes we need to capture stack trace on one debugger and use it
      later as a parent stack on another debugger (e.g. worker.postMessage).
      
      This CL includes following addition to our protocol and v8-inspector.h:
        - added Runtime.StackTraceId, this id represents stack trace captured
          on debugger with given id,
        - protocol client can fetch Runtime.StackTrace by
          Runtime.StacKTraceId using Debugger.getStackTrace method,
        - externalParent field is added to Debugger.paused event, it may
          contain external parent stack trace,
        - V8Inspector::storeCurrentStackTrace captures current stack trace
          and returns V8StackTraceId for embedder this id can be used as
          argument for V8Inspector::externalAsyncTaskStarted and
          V8Inspector::externalAsyncTaskFinished method. Any async stack
          trace captured between these calls will get passed external stack
          trace as external parent. These methods are designed to be called
          on different debuggers. If async task is scheduled and started on
          one debugger user should continue to use asyncTask* API,
        - Debugger.enable methods returns unique debuggerId.
      
      TBR=dgozman@chromium.org,jgruber@chromium.org
      
      Bug: chromium:778796
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4
      Reviewed-on: https://chromium-review.googlesource.com/786274
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49591}
      885a5669
    • Clemens Hammacher's avatar
      Revert "[inspector] introduced stackTraceId and externalAsyncTask API" · 4379533c
      Clemens Hammacher authored
      This reverts commit 3a41b697.
      
      Reason for revert: Break msvc: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/250
      
      Original change's description:
      > [inspector] introduced stackTraceId and externalAsyncTask API
      > 
      > Sometimes we need to capture stack trace on one debugger and use it
      > later as a parent stack on another debugger (e.g. worker.postMessage).
      > 
      > This CL includes following addition to our protocol and v8-inspector.h:
      >   - added Runtime.StackTraceId, this id represents stack trace captured
      >     on debugger with given id,
      >   - protocol client can fetch Runtime.StackTrace by
      >     Runtime.StacKTraceId using Debugger.getStackTrace method,
      >   - externalParent field is added to Debugger.paused event, it may
      >     contain external parent stack trace,
      >   - V8Inspector::storeCurrentStackTrace captures current stack trace
      >     and returns V8StackTraceId for embedder this id can be used as
      >     argument for V8Inspector::externalAsyncTaskStarted and
      >     V8Inspector::externalAsyncTaskFinished method. Any async stack
      >     trace captured between these calls will get passed external stack
      >     trace as external parent. These methods are designed to be called
      >     on different debuggers. If async task is scheduled and started on
      >     one debugger user should continue to use asyncTask* API,
      >   - Debugger.enable methods returns unique debuggerId.
      > 
      > Bug: chromium:778796
      > Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539
      > Reviewed-on: https://chromium-review.googlesource.com/754183
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49582}
      
      TBR=dgozman@chromium.org,pfeldman@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,jgruber@chromium.org
      
      Change-Id: I9b52354fa0841e5148596cf594317f2e5fe508ea
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:778796
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/786152Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49584}
      4379533c
    • Alexey Kozyatinskiy's avatar
      [inspector] introduced stackTraceId and externalAsyncTask API · 3a41b697
      Alexey Kozyatinskiy authored
      Sometimes we need to capture stack trace on one debugger and use it
      later as a parent stack on another debugger (e.g. worker.postMessage).
      
      This CL includes following addition to our protocol and v8-inspector.h:
        - added Runtime.StackTraceId, this id represents stack trace captured
          on debugger with given id,
        - protocol client can fetch Runtime.StackTrace by
          Runtime.StacKTraceId using Debugger.getStackTrace method,
        - externalParent field is added to Debugger.paused event, it may
          contain external parent stack trace,
        - V8Inspector::storeCurrentStackTrace captures current stack trace
          and returns V8StackTraceId for embedder this id can be used as
          argument for V8Inspector::externalAsyncTaskStarted and
          V8Inspector::externalAsyncTaskFinished method. Any async stack
          trace captured between these calls will get passed external stack
          trace as external parent. These methods are designed to be called
          on different debuggers. If async task is scheduled and started on
          one debugger user should continue to use asyncTask* API,
        - Debugger.enable methods returns unique debuggerId.
      
      Bug: chromium:778796
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539
      Reviewed-on: https://chromium-review.googlesource.com/754183Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49582}
      3a41b697
  34. 06 Nov, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] added new way to step into async task · 079c0fd8
      Alexey Kozyatinskiy authored
      It is preparation step for step-into-worker. There are few changes:
      - added breakOnAsyncCall flag for Debugger.stepInto. When flag is set
        and async task is scheduled before step-into finished, we pause
        execution with additional Debugger.paused event. This event contains
        additional scheduledAsyncTaskId field.
      - added Debugger.pauseOnAsyncTask. This method will pause execution as
        soon as given async task is started.
      
      This mechanism is replacement for Debugger.scheduleStepIntoAsync which
      can not be used between multiple targets.
      
      As result we can split async task scheduling in one target and
      requesting break for this async task running in another target.
      
      R=pfeldman@chromium.org
      
      Bug: chromium:778796
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I77be0c880d91253d333c54a23a4c084e7b8549e9
      Reviewed-on: https://chromium-review.googlesource.com/750071Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarPavel Feldman <pfeldman@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49127}
      079c0fd8