1. 10 Jun, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug] Consistent Step-In behavior for generator functions. · 887bacac
      Benedikt Meurer authored
      This change addresses inconsistencies wrt. to stepping into generator
      functions and breaking on the implicit initial yield. The new behavior
      is the following:
      
       1. Stepping into a generator function doesn't trigger "generator
          stepping", but rather pauses right before the initial yield
          (assuming there a no non-simple parameters in between).
       2. When paused on the initial yield and stepping into or over, we also
          don't turn on "generator stepping" immediately, but rather return to
          the caller and only enter "generator stepping" on SuspendGenerator
          bytecodes that correspond to `yield`s or `await`s in the source
          code.
      
      This matches the stepping behavior of regular functions more closely and
      seems like a good compromise.
      
      Fixed: chromium:901814
      Change-Id: Ifc6c174011df1afea183e2c6ec21de27d72b17a7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949099
      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@{#75066}
      887bacac
  2. 01 Jun, 2021 1 commit
  3. 29 Apr, 2021 1 commit
    • Benedikt Meurer's avatar
      [debugger] Remove "Restart frame" feature. · 93f85699
      Benedikt Meurer authored
      The "Restart frame" feature was implemented as part of LiveEdit and
      primarily used to support LiveEdit of active functions, but that was
      previously disabled as part of https://crrev.com/c/2846892 because it's
      too brittle and causes crashes when using seemingly unrelated features.
      The "Restart frame" feature was also available as a context menu item
      separately in the DevTools front-end, but that was also already removed
      as part of https://crrev.com/c/2854681 earlier. So all uses are gone
      now.
      
      This change works by marking Debugger.restartFrame as deprecated and
      having it respond with a ServerError all the time. It thus allows us to
      remove a whole bunch of machinery that was essentially just put in
      various places to support the restart_fp_ magic. In particular the
      debugger no longer needs any machine specific builtins now.
      
      Bug: chromium:1195927
      Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484
      Fixed: chromium:1203606
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74276}
      93f85699
  4. 15 Mar, 2021 1 commit
    • Kim-Anh Tran's avatar
      [debugger] Consider close-by functions when setting a breakpoint · a7c8a3ea
      Kim-Anh Tran authored
      This changes the behavior of SetBreakpointForScript to find more
      accurate break positions.
      
      Previously, setting a breakpoint would only consider the shared
      function info that contained the requested position for setting a
      breakpoint. More intuitively, a breakpoint should not necessarily
      be set in a function that contains the position, but in the closest
      breakable location that comes after the position we requested.
      
      To achieve this we:
      1. find the shared function info of the inner most function
      that contains the requested_position.
      This function's end position is used to find other shared function
      infos in step 2.
      
      2. search for all shared function infos that intersect with the
      range [requested_position, inner_most_function.break_position[.
      
      3. From the shared function infos extracted in 2, find the one
      that has the closest breakable location to requested_position.
      
      Also-By: bmeurer@chromium.org
      Fixed: chromium:1137141
      Change-Id: I4f4c6c3aac1ebea50cbcad9543b539ab1ded2b05
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742198
      Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73392}
      a7c8a3ea
  5. 02 Mar, 2021 1 commit
  6. 15 Feb, 2021 1 commit
  7. 10 Dec, 2020 1 commit
    • Peter Marshall's avatar
      [inspector] Throw during debug-eval when accessing function prototypes · 9691c5cf
      Peter Marshall authored
      Function prototypes can be lazily allocated. This means they go into the
      temporary objects set that debug-eval uses to figure out if a write
      will be side-effect free.
      
      We were incorrectly classifying writes to function prototypes as
      side-effect free because the prototype happened to be lazily allocated
      when we first accessed it during debug-eval, but was actually reachable
      from the function (not allocated temporarily).
      
      To do this we introduced a way to temporarily turn off the temporary
      object tracking, and we use it when lazily allocating function
      prototypes.
      
      This could mean that we incorrectly report side-effects when writing to
      function prototypes for functions which were themselves created during
      debug-eval side-effect free mode. However, it's unclear if this is a
      problem, because function declarations set global variables which would
      already throw due to side-effects.
      
      Bug: chromium:1154193
      Change-Id: I444a673662095f6deabaafdce3cdf3d86b71446d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581968Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71692}
      9691c5cf
  8. 26 Nov, 2020 1 commit
  9. 20 Nov, 2020 1 commit
  10. 18 Nov, 2020 1 commit
  11. 17 Nov, 2020 1 commit
  12. 11 Aug, 2020 1 commit
  13. 07 May, 2020 1 commit
  14. 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
  15. 18 Dec, 2019 1 commit
  16. 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
  17. 22 Nov, 2019 1 commit
  18. 15 Nov, 2019 1 commit
  19. 13 Sep, 2019 1 commit
  20. 23 Aug, 2019 1 commit
  21. 22 Aug, 2019 2 commits
  22. 12 Jul, 2019 1 commit
  23. 13 Jun, 2019 1 commit
  24. 24 May, 2019 1 commit
  25. 23 May, 2019 1 commit
  26. 22 May, 2019 1 commit
  27. 21 May, 2019 1 commit
  28. 08 May, 2019 1 commit
  29. 09 Apr, 2019 1 commit
  30. 04 Apr, 2019 1 commit
  31. 27 Feb, 2019 1 commit
  32. 01 Feb, 2019 2 commits
  33. 26 Dec, 2018 1 commit
  34. 17 Dec, 2018 1 commit
  35. 08 Dec, 2018 1 commit
  36. 27 Nov, 2018 1 commit
  37. 31 Oct, 2018 2 commits