1. 30 Sep, 2020 1 commit
  2. 08 Sep, 2020 1 commit
  3. 01 Sep, 2020 1 commit
  4. 18 Aug, 2020 1 commit
  5. 11 Aug, 2020 1 commit
  6. 10 Jun, 2020 1 commit
  7. 09 Jun, 2020 1 commit
  8. 05 May, 2020 2 commits
  9. 04 May, 2020 1 commit
  10. 15 Apr, 2020 1 commit
  11. 26 Mar, 2020 1 commit
  12. 17 Mar, 2020 1 commit
  13. 09 Mar, 2020 1 commit
  14. 24 Feb, 2020 1 commit
  15. 06 Feb, 2020 1 commit
    • Z Nguyen-Huu's avatar
      Reland "[wasm] Tierdown wasm module upon "Debugger.enable"" · 1f7861c8
      Z Nguyen-Huu authored
      This is a reland of 410ca4c5
      
      Skip new test for unsupported liftoff architecture.
      Previously, if there is some unsupported liftoff functions, it fall
      through Turbofan but recompilation didn't catch and count it. This CL
      fixes it by using requested_tier on finished units.
      
      Avoid to tier down asm.js.
      Introduce reached recompilation tier to monitor recompilation progress.
      
      Original change's description:
      > [wasm] Tierdown wasm module upon "Debugger.enable"
      >
      > Put a logic in Wasm Engine to tier down all existing modules per isolate
      > when debugger is enabled. This CL does not handle new module added after
      > debugger is enabled yet.
      >
      > Bug: v8:9654
      > Change-Id: I87060f5c416506543fcaf231bff9999d06ba4c0d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013692
      > Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66017}
      
      TBR=szuend@chromium.org,bmeurer@chromium.org
      
      Bug: v8:9654
      Change-Id: I6014ae52d1e04726e64ee9267c5ce559090414d7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031744
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66164}
      1f7861c8
  16. 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
  17. 30 Jan, 2020 1 commit
    • Eric Leese's avatar
      Revert "[wasm] Tierdown wasm module upon "Debugger.enable"" · fb96381b
      Eric Leese authored
      This reverts commit 410ca4c5.
      
      Reason for revert: This was causing Chrome to hang when debugging large wasm binaries.
      
      Clean revert except for modification to test/debugger/debugger.status
      
      Bug: chromium:1047210, v8:9654
      
      Original change's description:
      > [wasm] Tierdown wasm module upon "Debugger.enable"
      >
      > Put a logic in Wasm Engine to tier down all existing modules per isolate
      > when debugger is enabled. This CL does not handle new module added after
      > debugger is enabled yet.
      >
      > Bug: v8:9654
      > Change-Id: I87060f5c416506543fcaf231bff9999d06ba4c0d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013692
      > Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66017}
      
      TBR=clemensb@chromium.org,bmeurer@chromium.org,duongn@microsoft.com,szuend@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9654
      Change-Id: Id49e8c69f8212e95e698d7e7267056fb2eb7e60a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030737
      Auto-Submit: Eric Leese <leese@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66054}
      fb96381b
  18. 29 Jan, 2020 1 commit
  19. 22 Jan, 2020 1 commit
  20. 17 Jan, 2020 1 commit
  21. 18 Dec, 2019 2 commits
    • Z Nguyen-Huu's avatar
      [wasm] Support remove breakpoint · b0dbe454
      Z Nguyen-Huu authored
      In setting breakpoint in wasm, we can find wasm script from location but
      in removing a breakpoint, only breakpoint id is provided. For wasm, we
      have a list of all BreakPointInfo objects attached to the Script. From
      breakpoint id, we iterates all scripts to find the targeted breakpoint
      and remove it.
      
      Bug: chromium:837572
      Change-Id: Ia5d0fb7d804fb98270b2103232bc10eb5d4f93a3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1959749
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65505}
      b0dbe454
    • Simon Zünd's avatar
      Store JSMessageObject on rejected promises · b15c02d0
      Simon Zünd authored
      When V8 throws an uncaught exception, we store a JSMessageObject
      with a stack trace and source positions on the isolate itself.
      The JSMessageObject can be retrieved by a TryCatch scope
      and is used by the inspector to provide additional information to the DevTools
      frontend (besides the exception).
      
      Introducing top-level await for REPL mode causes all thrown exceptions
      to be turned into a rejected promise. The implicit catch block that does this
      conversion clears the JSMessageObject from the isolate as to not leak memory.
      
      This CL preserves the JSMessageObject when the debugger is active and stores
      the JSMessageObject on the rejected promise itself. The inspector is changed
      to retrieve the JSMessageObject in the existing catch handler and pass the
      information along to the frontend.
      
      Drive-by: This CL removes a inspector test that made assumptions when a promise
      is cleaned up by the GC. These assumptions no longer hold since we hold on to
      the promise longer.
      
      Bug: chromium:1021921
      Change-Id: Id0380e2cf3bd79aca05191bc4f3c616f6ced8db7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967375
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65497}
      b15c02d0
  22. 09 Dec, 2019 1 commit
  23. 04 Dec, 2019 1 commit
    • Joyee Cheung's avatar
      [class] implement inspector support for private instance methods · 963ff849
      Joyee Cheung authored
      This patch implements inspector support for private instance methods:
      
      - Previously to implement brand checking for instances with private
        instance methods we store the brand both as the value with the brand
        itself as the key in the stances. Now we make the value the context
        associated with the class instead.
      - To retrieve the private instance methods and accessors from the
        instances at runtime, we look into the contexts stored with the
        brands, and analyze the scope info to get the names as well as
        context slot indices of them.
      - This patch extends the `PrivatePropertyDescriptor` in the inspector
        protocol to include optional `get` and `set` fields, and make the
        `value` field optional (similar to `PropertyDescriptor`s).
        Private fields or private instance methods are returned in the
        `value` field while private accessors are returned in the `get`
        and/or `set` field. Property previews for the instaces containing
        private instance methods and accessors are also updated similarly,
        although no additional protocol change is necessary since the
        `PropertyPreview` type can already be used to display accessors.
      
      Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
      
      Bug: v8:9839, v8:8330
      Change-Id: If37090bd23833a18f75deb1249ca5c4405ca2bf2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934407
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65337}
      963ff849
  24. 06 Nov, 2019 1 commit
  25. 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
  26. 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
  27. 27 Sep, 2019 1 commit
  28. 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
  29. 13 Sep, 2019 1 commit
  30. 08 Jul, 2019 1 commit
  31. 28 Jun, 2019 1 commit
  32. 24 May, 2019 1 commit
  33. 08 May, 2019 1 commit
  34. 03 May, 2019 1 commit
  35. 04 Apr, 2019 1 commit
  36. 27 Feb, 2019 2 commits
  37. 31 Oct, 2018 1 commit