- 10 Jun, 2021 1 commit
-
-
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: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#75066}
-
- 18 Jun, 2018 2 commits
-
-
Alexey Kozyatinskiy authored
This is a reland of 4363a693 Original change's description: > [inspector] fixed location of top level function return > > We should pass false as has_braces argument to create FunctionLiteral > for top level function. > > R=dgozman@chromium.org,bmeurer@chromium.org > TBR=bmeurer@chromium.org > > Bug: none > Change-Id: I397f31b562d32c71f3a12bfc9ceeed16c367aa80 > Reviewed-on: https://chromium-review.googlesource.com/1098018 > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53769} TBR=dgozman@chromium.org Bug: v8:7858 Change-Id: Ie636bc101f9d29d9d40bd10b96e62da6505c2734 Reviewed-on: https://chromium-review.googlesource.com/1104497 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#53808}
-
Clemens Hammacher authored
This reverts commit 4363a693. Reason for revert: Seems to break layout tests: https://ci.chromium.org/buildbot/client.v8.fyi/V8-Blink%20Linux%2064/24146 Original change's description: > [inspector] fixed location of top level function return > > We should pass false as has_braces argument to create FunctionLiteral > for top level function. > > R=dgozman@chromium.org,bmeurer@chromium.org > TBR=bmeurer@chromium.org > > Bug: none > Change-Id: I397f31b562d32c71f3a12bfc9ceeed16c367aa80 > Reviewed-on: https://chromium-review.googlesource.com/1098018 > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53769} TBR=dgozman@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: none Change-Id: I4495f6723daed63b7a38b0d3c3637724f6c2d484 Reviewed-on: https://chromium-review.googlesource.com/1104017Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53775}
-
- 15 Jun, 2018 1 commit
-
-
Alexey Kozyatinskiy authored
We should pass false as has_braces argument to create FunctionLiteral for top level function. R=dgozman@chromium.org,bmeurer@chromium.org TBR=bmeurer@chromium.org Bug: none Change-Id: I397f31b562d32c71f3a12bfc9ceeed16c367aa80 Reviewed-on: https://chromium-review.googlesource.com/1098018 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#53769}
-
- 18 Jul, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
Nop bytecodes are required only for break locations in debugger. Since nop bytecode doesn't change program state we can remove all of them. There are at least two changes which this CL produce: - we don't provide break position when we load local variable (still provide when load variable from global), - we don't provide break position for statements without actual break positions (e.g. "a;") - these expressions should be super rare and user always can set breakpoint before or after this statement. More details in one pager: https://docs.google.com/a/google.com/document/d/1JXlQpfMa9vRojbE272b6GMBbrfh6m_00135iAUOJEz8/edit?usp=sharing Bug: v8:6425 Change-Id: I4aee73d497a84f7b5d89caa6dda6d3060567dfda Reviewed-on: https://chromium-review.googlesource.com/543161Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46742}
-
- 14 Jul, 2017 1 commit
-
-
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: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
-
- 31 May, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
In current implementation in expressions like await foo() we have break location right after foo call and before actual await. And we additionally have a lot of other statement locations because of do scope. Let's move async debugging closer to sync debugging and introduce only one break location for await - before awaited function call. Bug: v8:6425,v8:6162 Change-Id: I7568767856022c49101e7f3b7e39a2e401d21644 Reviewed-on: https://chromium-review.googlesource.com/514046Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45625}
-
- 24 May, 2017 1 commit
-
-
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}
-
- 18 May, 2017 1 commit
-
-
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: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#45406}
-
- 15 May, 2017 2 commits
-
-
Deepti Gandluri authored
This reverts commit 98927ea5. Reason for revert: Breaks Mac GC Stress bot. https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Mac%20GC%20Stress/builds/13299/steps/Mjsunit/logs/for-await-of Original change's description: > [ignition] Be smarter about register allocation in VisitSuspend > > 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. > > Bug: v8:6379 > Change-Id: I08a617a44f99706cfff09bf86fb0a25a9cd6e032 > Reviewed-on: https://chromium-review.googlesource.com/503593 > Commit-Queue: Adam Klein <adamk@chromium.org> > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45318} TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,kozyatinskiy@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Bug: v8:6379 Change-Id: I787fc3811c4f33a8021cf9170d43a74ed9b55d1c Reviewed-on: https://chromium-review.googlesource.com/506548Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#45319}
-
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. Bug: v8:6379 Change-Id: I08a617a44f99706cfff09bf86fb0a25a9cd6e032 Reviewed-on: https://chromium-review.googlesource.com/503593 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45318}
-
- 04 May, 2017 1 commit
-
-
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: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
-
- 22 Mar, 2017 1 commit
-
-
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}
-
- 07 Mar, 2017 1 commit
-
-
mvstanton authored
BUG=v8:5267, chromium:692409 Review-Url: https://codereview.chromium.org/2720713003 Cr-Commit-Position: refs/heads/master@{#43638}
-
- 27 Feb, 2017 2 commits
-
-
kozyatinskiy authored
BUG=none R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2710903003 Cr-Commit-Position: refs/heads/master@{#43459}
-
kozyatinskiy authored
This test helps to prevent regressions during work on new break locations. BUG=none R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2719763002 Cr-Commit-Position: refs/heads/master@{#43458}
-