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. 18 Jun, 2018 2 commits
  3. 15 Jun, 2018 1 commit
  4. 18 Jul, 2017 1 commit
  5. 14 Jul, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] improve return position of explicit return in non-async function · 08965860
      Alexey Kozyatinskiy authored
      Goal of this CL: explicit return from non-async function has position after
      return expression as return position (will unblock [1]).
      
      BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
      If one of these methods is called then next generated bytecode will get passed
      position. It's general treatment for most cases.
      Unfortunately it doesn't work for Returns:
      - debugger requires source positions exactly on kReturn bytecode in stepping
        implementation,
      - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
        generates more then one bytecode and general solution will put return position
        on first generated bytecode,
      - it's not easy to split BuildReturn function into two parts to allow something
        like following in BytecodeGenerator::VisitReturnStatement since generated
        bytecodes are actually controlled by execution_control().
      ..->BuildReturnPrologue();
      ..->SetReturnPosition(stmt);
      ..->Return();
      
      In this CL we pass ReturnStatement through ExecutionControl and use it for
      position when we emit return bytecode right here.
      
      So this CL only will improve return position for returns inside of non-async
      functions, I'll address async functions later.
      
      [1] https://chromium-review.googlesource.com/c/543161/
      
      Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
      Reviewed-on: https://chromium-review.googlesource.com/560738
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46687}
      08965860
  6. 31 May, 2017 1 commit
  7. 24 May, 2017 1 commit
    • kozyatinskiy's avatar
      [inspector] removed call break location from for-of loop · fb78710c
      kozyatinskiy authored
      There are two break locations at the same source location by desugaring:
      - call iterator.next,
      - before variable assignment.
      
      Additionally location for for..of loops is moved from before "of" to before each variable expression.
      
      We should not report first implicit call to avoid user confusion. User still able to go into .next function with both scenarios:
      - when this call is reached by stepOver or stepInto from previous line,
      - when this call is reached because of breakpoint at current line.
      
      BUG=v8:6425
      R=dgozman@chromium.org,jgruber@chromium.org
      
      Review-Url: https://codereview.chromium.org/2893313002
      Cr-Commit-Position: refs/heads/master@{#45509}
      fb78710c
  8. 18 May, 2017 1 commit
    • Adam Klein's avatar
      Reland: [ignition] Be smarter about register allocation in VisitSuspend · 5dc2d6f6
      Adam Klein authored
      Split BytecodeGenerator::VisitSuspend into two pieces, one for
      building the suspension code and one for resumption (these
      are split into separate Build methods for convenience).
      Each gets its own RegisterAllocationScope, which allows us to
      reduce the register file size of the empty generator by 1.
      
      For consistency, rename VisitGeneratorPrologue() to
      BuildGeneratorPrologue() to match the names of the two
      newly-created methods.
      
      This relands the patch originally committed in
      98927ea5, as the test failure
      due to that change was a code flushing bug. Code flushing was
      disabled in de4a4095.
      
      R=rmcilroy@chromium.org
      
      Bug: v8:6379
      Change-Id: Ifb4deafea99693c0a4e8646cf4e9884c7374cfc6
      Reviewed-on: https://chromium-review.googlesource.com/508814Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45406}
      5dc2d6f6
  9. 15 May, 2017 2 commits
  10. 04 May, 2017 1 commit
    • Caitlin Potter's avatar
      [es6] don't use do-expressions to desugar ES6 classes · c6540ab1
      Caitlin Potter authored
      Removes the do-expression wrapping, modifies BytecodeGenerator change
      to enter a class literal's block scope if needed.
      
      This does not solve the actual bug in v8:6322, but helps mitigate it in
      simple cases. The bug is caused by BytecodeGenerator not allocating a
      large enough array of context registers to hold its entire stack,
      allowing non-context registers to be overwritten during PushContext and
      PopContext bytecodes.
      
      Nevertheless, I like the idea of not depending on do-expressions when
      possible, so I think it's worth doing anyways.
      
      BUG=v8:6322
      R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org
      
      Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a
      Reviewed-on: https://chromium-review.googlesource.com/491074
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDaniel Ehrenberg <littledan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45110}
      c6540ab1
  11. 22 Mar, 2017 1 commit
    • kozyatinskiy's avatar
      [inspector] changed a way of preserving stepping between tasks · 760c56bd
      kozyatinskiy authored
      Indisputable profit:
      - correct break location in next task (see tests),
      - stepOver with async await never lands in random code (see related test and issue),
      - inspector doesn't store current stepping state in debugger agent and completely trust V8 - step to new inspector-V8 design (I will finish design doc soon).
      - willExecuteScript and didExecuteScript instrumentation could be removed from code base - reduce probability of future errors.
      - finally - less code,
      - stepping implementation in V8 makes another step to follow our stepping strategy (stepOut should do stepInto and break when exit current frame) (another one one page design doc based on @aandrey comment is coming),
      - knowledge about existing of context groups is still inspector-only.
      
      Disputable part is related to super rare scenario when in single isolate we have more then one context group id with enabled debugger agent:
      - if one agent request break in own context (stepping, pause, e.t.c.) then we ignore all breaks in another agent. From one hand it looks like good: user clicks stepInto and they don't expect that execution could be paused by another instance of DevTools in unobservable from current DevTools way (second DevTools will get paused notification and run nested message loop). From another hand we shouldn't ignore breakpoints or debugger statement never. In general, I think that proposed behavior is rathe feature then issue.
      - and disadvantage, on attempt to break in non-target context group id we just call StepOut until reach target context group id, step out call could deoptimize code in non related to current debugger agent context. But break could happens only in case of debugger stmt or breakpoint - sound like minor issue. Ignoring break on exception sounds like real issue but by module of rareness of this case I think we can ignore this.
      
      Implementation details:
      - when debugger agent request break for any reason it passes target context group id to V8Debugger - last agent requesting break is preferred.
      - when V8Debugger gets BreakProgramRequested notification from V8, it checks current context group id against target context group id, if they match then just process break as usual otherwise makes StepOut action,
      - debug.cc at the end of microtask if last_scheduled_action is StepOut, schedules StepIn and will break on first instruction in next task.
      
      BUG=chromium:654022
      R=dgozman@chromium.org,yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2748503002
      Cr-Commit-Position: refs/heads/master@{#44034}
      760c56bd
  12. 07 Mar, 2017 1 commit
  13. 27 Feb, 2017 2 commits