1. 01 Oct, 2021 2 commits
    • Benedikt Meurer's avatar
      [debug] Set breakpoints correctly right after function literals. · 6d25f20f
      Benedikt Meurer authored
      The logic to locate the correct function to set a breakpoint in based
      on script position was treating SharedFunctionInfo::EndPosition() as
      inclusive rather than exclusive. There are various assumptions all over
      the Debugger that seem to demand this treatment for the toplevel script.
      But it's definitely wrong for function literals.
      
      Fixed: chromium:1253277
      Change-Id: I3421703673f4d78aee28e923e03e2fca24bc06ac
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197715
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77186}
      6d25f20f
    • Benedikt Meurer's avatar
      [inspector] Consistently treat promise rejections as side-effecting. · 0195a5eb
      Benedikt Meurer authored
      Previously we'd treat %_AsyncFunctionReject (and %AsyncFunctionReject)
      as side-effect free (in async functions), but that's not correct, since
      promise rejections have side-effects (at the very least triggering the
      unhandled promise rejection machinery in the browser).
      
      This required a minor refactoring as previously we'd classify functions
      as side-effecting or not depending on whether they contain any calls to
      side-effecting intrinsics, no matter whether this call is actually
      executed or not. That would break REPL mode however if we'd generally
      treat all async functions with %_AsyncFunctionReject intrinsic calls as
      side-effecting, so instead of performing the intrinsic checks ahead of
      time, we now perform the test at execution time.
      
      Before: https://imgur.com/5BvJP9d.png
      After: https://imgur.com/10FanNr.png
      Fixed: chromium:1249275
      Change-Id: Ib06f945ba21f1e06ee9b13a1363fad342464fd9a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197712
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77183}
      0195a5eb
  2. 20 Sep, 2021 1 commit
  3. 06 Sep, 2021 1 commit
  4. 24 Aug, 2021 1 commit
  5. 05 Aug, 2021 1 commit
  6. 22 Jul, 2021 1 commit
  7. 19 Jul, 2021 1 commit
  8. 14 Jul, 2021 1 commit
    • Benedikt Meurer's avatar
      [refactor] Introduce dedicated WasmScript::SetBreakPointOnEntry(). · 95b2f02d
      Benedikt Meurer authored
      Previously we had passed kOnEntryBreakpointPosition as a marker through
      the regular SetBreakPointForScript() logic and handled that specially in
      WasmScript, however this instrumentation breakpoint is special and gets
      in the way of returning more information about a regular breakpoint in
      case of crbug.com/700516, so I decided to just isolate that into it's
      own method, especially since the only user already special-cases Wasm
      anyways.
      
      Bug: chromium:1162229, chromium:700516
      Change-Id: Ie7966c1701365a4b03710d6dc32cc8278577ee3a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3026711
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75724}
      95b2f02d
  9. 07 Jul, 2021 1 commit
  10. 06 Jul, 2021 1 commit
  11. 05 Jul, 2021 2 commits
  12. 01 Jul, 2021 1 commit
  13. 22 Jun, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug] Default to last break index. · 01605d56
      Benedikt Meurer authored
      When looking up the break index for a given source position, default to
      the last break index if there is neither a precise match nor a breakable
      position after the source position (in which case we still pick the
      first candidate).
      
      Fixed: chromium:1222065
      Bug: chromium:901819, chromium:782461, chromium:1222060
      Change-Id: I10d6a086b2d5fadc9e6dca0c49ed4187eb0359ff
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972917
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
      Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75284}
      01605d56
  14. 14 Jun, 2021 1 commit
  15. 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
  16. 07 Jun, 2021 1 commit
  17. 01 Jun, 2021 1 commit
  18. 10 May, 2021 2 commits
  19. 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
  20. 23 Apr, 2021 1 commit
  21. 19 Apr, 2021 1 commit
  22. 12 Apr, 2021 1 commit
  23. 22 Mar, 2021 1 commit
  24. 16 Mar, 2021 1 commit
  25. 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
  26. 11 Mar, 2021 3 commits
    • Clemens Backes's avatar
      Reland "[no-wasm] Exclude src/wasm from compilation" · 3f9ff062
      Clemens Backes authored
      This is a reland of 80f5dfda. A condition
      in pipeline.cc was inverted, which lead to a CSA verifier error.
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      TBR=jgruber@chromium.org
      
      Bug: v8:11238
      Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73348}
      3f9ff062
    • Clemens Backes's avatar
      Revert "[no-wasm] Exclude src/wasm from compilation" · 92bc3d38
      Clemens Backes authored
      This reverts commit 80f5dfda.
      
      Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=​jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      Bug: v8:11238
      Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73346}
      92bc3d38
    • Clemens Backes's avatar
      [no-wasm] Exclude src/wasm from compilation · 80f5dfda
      Clemens Backes authored
      This is the biggest chunk, including
      - all of src/wasm,
      - torque file for wasm objects,
      - torque file for wasm builtins,
      - wasm builtins,
      - wasm runtime functions,
      - int64 lowering,
      - simd scala lowering,
      - WasmGraphBuilder (TF graph construction for wasm),
      - wasm frame types,
      - wasm interrupts,
      - the JSWasmCall opcode,
      - wasm backing store allocation.
      
      Those components are all recursively entangled, so I found no way to
      split this change up further.
      
      Some includes that were recursively included by wasm headers needed to
      be added explicitly now.
      
      backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      because it only tests wasm backing stores. This file is excluded from
      no-wasm builds then.
      
      R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      
      Bug: v8:11238
      Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73344}
      80f5dfda
  27. 08 Mar, 2021 1 commit
  28. 03 Mar, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug] Instantiate accessors only once. · e9873bf1
      Benedikt Meurer authored
      When retrieving an API accessor function (i.e. either the getter or the
      setter) for which the lazy accessor mechanism is used (i.e. where the
      actual JSFunction is created lazily and only the FunctionTemplateInfo)
      is around, we thus far created a fresh JSFunction every time the
      accessor function is requested, but that's observably wrong behavior,
      since the accessors are JavaScript objects with identity. We currently
      rely on the instantiation cache to guarantee identity, but there's no
      reason why we couldn't instead just put the instantiated JSFunction into
      the AccessorPair.
      
      Fixing this to only instantiate the lazy accessor pair only once, upon
      first time it's requested, coincidentally also simplifies (and fixes)
      the API accessor breakpoint machinery. This was previously lacking
      support for walking dictionary prototype objects and forcibly
      instantiating the lazy accessor pairs with break points. However, all
      this magic in the debugger is no longer necessary when we ensure that
      the lazy accessor pair component is generally only instantiated once.
      
      Bug: v8:178, v8:7596, chromium:986063, chromium:496666
      Change-Id: I41d28378010716c96c8ecf7c3f1247765f8bc669
      Fixed: chromium:1163547
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731527Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73163}
      e9873bf1
  29. 02 Mar, 2021 2 commits
    • Clemens Backes's avatar
      [no-wasm] Remove wasm debugging support · 8890bb21
      Clemens Backes authored
      This removes all wasm includes from src/debug and src/inspector if
      webassembly is disabled (v8_enable_webassembly=false). It also removes
      the definition of {WasmValueObject} and {v8::debug::WasmScript}.
      This will allow to later fully exclude the src/wasm directory from
      compilation (once other components are fixed).
      
      R=bmeurer@chromium.org, machenbach@chromium.org
      
      Bug: v8:11238
      Change-Id: I41a1d83d01fbb6c015cdfd6cc063bad90052505d
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726506Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73138}
      8890bb21
    • Benedikt Meurer's avatar
      [debug] Don't put a source position on internal `Return`s. · 06359f74
      Benedikt Meurer authored
      Be explicit about source positions for `Return`s in the
      BytecodeGenerator, and only do self-healing explicitly in the
      `ReturnStatement` translation, where an end position of
      `kNoSourcePosition` is turned into the return position of the
      function literal.
      
      This allows us to reason more easily about which `Return`s actually
      receive a meaningful source position, and in particular it allows us
      to construct the internal `Return`s for `yield` and `yield*` with no
      source position attached to them. Previously they'd get the source
      position for the implicit (final) return attached to it, which confused
      the debugger and led to breakpoints being set in the completely wrong
      spot.
      
      Considering the simplified example
      
      ```
      function* foo(){
        var a = 1;
      }
      ```
      
      this would previously generate the following bytecode
      
      ```
              0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
              4 : Mov <closure>, r2
              7 : Mov <this>, r3
       13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
             14 : Star0
       13 E> 15 : SuspendGenerator r0, r0-r1, [0]
             20 : ResumeGenerator r0, r0-r1
             24 : Star2
             25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
             29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
             33 : Ldar r2
       13 E> 35 : Throw
             36 : Ldar r2
       30 S> 38 : Return    <=========================== internal Return
       27 S> 39 : LdaSmi [1]
             41 : Star1
             42 : LdaUndefined
       30 S> 43 : Return
      ```
      
      where everything between offset 4 and 42 corresponds to the implicit
      yield at the beginning of every generator function, in particular the
      code between 20 and 42 corresponds to that initial yields resumption
      logic. Notice how the internal Return at offset 38 gets assigned the
      source position of the function literal (the same as the implicit
      return at the end). This confuses the debugger quite a bit when trying
      to set a breakpoint on the closing brace, since it's going in bytecode
      order and will thus discover the `Return` at offset 38 first (matching
      the source position 30 it's currently looking for) and setting the
      breakpoint there. This `Return` bytecode however is only executed when
      the generator is resumed via `GeneratorPrototype.return()`, and it'll
      not hit when the developer uses the generator normally, which is not
      the desired behavior and extremely confusing (especially since stepping
      on the other hand works as expected).
      
      With this patch, we no longer slap a source position (and in particular
      not the function literal's return position) onto these internal
      `Return`s as you can see from the generated bytecode below:
      
      ```
             0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
             4 : Mov <closure>, r2
             7 : Mov <this>, r3
      13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
            14 : Star0
      13 E> 15 : SuspendGenerator r0, r0-r1, [0]
            20 : ResumeGenerator r0, r0-r1
            24 : Star2
            25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
            29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
            33 : Ldar r2
      13 E> 35 : Throw
            36 : Ldar r2
            38 : Return
      27 S> 39 : LdaSmi [1]
            41 : Star1
            42 : LdaUndefined
      30 S> 43 : Return
      ```
      
      This also allows us to remove the break position finding hack that was
      kept in BreakIterator::BreakIndexFromPosition() for generators and
      modules.
      
      Fixed: chromium:901819
      Change-Id: If19a6b26e2622d49b6b5e54bf7a162747543f970
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727820Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73119}
      06359f74
  30. 24 Feb, 2021 2 commits
  31. 23 Feb, 2021 1 commit
  32. 17 Feb, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug][inspector] Use first rather than closest break location. · 16b0767a
      Benedikt Meurer authored
      In case there's no exact match for the breakable location in
      SetBreakpoint(), don't try to find the syntactically closest break
      location, but rather find the first possible break location in bytecode
      order. In particular when trying to set a breakpoint in a line with
      for-of or an array destruction, there's no point in going for the
      syntactically closest to the beginning of the line, but rather go for
      the semantically first, as the intiution for setting a breakpoint on a
      line is that the debugger stops before it executes anything on said
      line. In the example
      
      ```
      var [^a, ^b] = ^func();
      ```
      
      there are three possible break locations, and the correct one is the
      last one as the call to func will happen first at runtime.
      
      For generators that's currently broken because of the implicit initial
      yield, and same with modules (see crbug.com/901819), so we keep the
      previous behavior of finding the closest breakable location, and will
      fix that independently in a follow up CL.
      
      Bug: chromium:901819
      Fixed: chromium:782461
      Also-By: yangguo@chromium.org
      Change-Id: Ie724c5cb08e5f4edd90a450d99e001dff06bbe7a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696586
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72813}
      16b0767a
  33. 16 Feb, 2021 1 commit