This function can be used to set breakpoint on any function call,
including native functions without source code, for them new method is
only one way to set breakpoint.
R=dgozman@chromium.org
Bug: chromium:828076
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iae8f4805b6e860a7ca008041fdfbe75e43a1959c
Reviewed-on: https://chromium-review.googlesource.com/1023128
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52745}
The handling of wasm breakpoints was prone to forget previously set
breakpoints when inserting new ones. In particular, adding breakpoints
in reverse order or adding more than 4 breakpoints would fail.
Change-Id: I94f314e86bdf9b53a4170ce1b6b47339b7cb7848
Reviewed-on: https://chromium-review.googlesource.com/1019302
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52691}
This CL allows SetPrototypeAdd and ArrayIteratorPrototypeNext
to be called on temporary objects during side effect free evaluation.
Bug: v8:7588
Change-Id: Id77848e48d98c243de91bc6c0fae5a0877e693d4
Reviewed-on: https://chromium-review.googlesource.com/998439
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52548}
This is a reland of 7a2c371383
Original change's description:
> [debug] introduced runtime side effect check
>
> This CL demonstrates minimum valuable addition to existing debug evaluate
> without side effects mechanism.
> With this CL user can evaluate expressions like:
> [a,b] // create any kind of temporary array literals
> [a,b].reduce((x,y) => x + y, 0); // use reduce method
> [1,2,3].fill(2); // change temporary arrays
>
> The core idea: any change of the object created during evaluation without
> side effects is side effect free. As soon as we try to store this temporary
> object to object existed before evaluation we will terminate execution.
>
> Implementation:
> - track all objects allocated during evaluation and mark them as temporary,
> - patch all bytecodes which change objects.
>
> A little more details (including performance analysis): [1].
>
> [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
>
> Bug: v8:7588
> Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
> Reviewed-on: https://chromium-review.googlesource.com/972615
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52370}
Bug: v8:7588
Change-Id: Ibc92bf19155f2ddaedae39b0c576b994e84afcf8
Reviewed-on: https://chromium-review.googlesource.com/996760
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52373}
This reverts commit 7a2c371383.
Reason for revert: msan is broken
Original change's description:
> [debug] introduced runtime side effect check
>
> This CL demonstrates minimum valuable addition to existing debug evaluate
> without side effects mechanism.
> With this CL user can evaluate expressions like:
> [a,b] // create any kind of temporary array literals
> [a,b].reduce((x,y) => x + y, 0); // use reduce method
> [1,2,3].fill(2); // change temporary arrays
>
> The core idea: any change of the object created during evaluation without
> side effects is side effect free. As soon as we try to store this temporary
> object to object existed before evaluation we will terminate execution.
>
> Implementation:
> - track all objects allocated during evaluation and mark them as temporary,
> - patch all bytecodes which change objects.
>
> A little more details (including performance analysis): [1].
>
> [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
>
> Bug: v8:7588
> Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
> Reviewed-on: https://chromium-review.googlesource.com/972615
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52370}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,leszeks@chromium.org
Change-Id: Ied1739c6308b13a4981189e0999f5912316cf456
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7588
Reviewed-on: https://chromium-review.googlesource.com/996135
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52371}
This CL demonstrates minimum valuable addition to existing debug evaluate
without side effects mechanism.
With this CL user can evaluate expressions like:
[a,b] // create any kind of temporary array literals
[a,b].reduce((x,y) => x + y, 0); // use reduce method
[1,2,3].fill(2); // change temporary arrays
The core idea: any change of the object created during evaluation without
side effects is side effect free. As soon as we try to store this temporary
object to object existed before evaluation we will terminate execution.
Implementation:
- track all objects allocated during evaluation and mark them as temporary,
- patch all bytecodes which change objects.
A little more details (including performance analysis): [1].
[1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
Bug: v8:7588
Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
Reviewed-on: https://chromium-review.googlesource.com/972615
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52370}
This patch teaches Runtime.callFunctionOn to run evals inside its
task. This is aligned with how Runtime.evaluate works.
R=kozy
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I3189beebc9020703d2b2e23a7c828a2394d43910
Reviewed-on: https://chromium-review.googlesource.com/994070
Commit-Queue: Andrey Lushnikov <lushnikov@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52339}
- Label as "bigint" in DevTools heap snapshot viewer
- Treat as new primitive in injected-script-source
- Show primitive value as property for BigIntObject
- Adds the "n" suffix onto description, both with/without inspector
being present
Bug: v8:7486
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I47a02e32f9bdd9124a6c91056965574ecd443867
Reviewed-on: https://chromium-review.googlesource.com/940804
Commit-Queue: Erik Luo <luoe@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51855}
The debugger script implementation had its own way to write
uint32_t values to a string as hex values. This removes the
custom code and uses a shared implementation in String16Builder
instead.
The observable effect is that script hashes are now lower-case
and the character sequence is reversed for each 8-character
pair.
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib21769fbe10c24055fbd3fa9573bc5c2d72f6a74
Reviewed-on: https://chromium-review.googlesource.com/951303
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51801}
Previously GetSharedFunctionInfoForStreamedScript didn't either check the
compilation cache or put the result of compilation into the compilation
cache. This would mean future compiles would need to re-parse / compile
the same script even if the isolate had already seen it. This CL
fixes this.
Also refactors the compilation pipelines to ensure we call debug->OnAfterCompile()
for all script compiles even when loading from a cache.
BUG=v8:5203
Change-Id: I4b06bdfc566425f4e6d70fc3e6e080b0dc497d48
Reviewed-on: https://chromium-review.googlesource.com/939464
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51607}
This reverts commit 2542720357.
Reason for revert: code-coverage failures on gc-stress bot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/17956
Original change's description:
> Reland: [Compiler] Use CompilationCache for StreamedScript compilation.
>
> Previously GetSharedFunctionInfoForStreamedScript didn't either check the
> compilation cache or put the result of compilation into the compilation
> cache. This would mean future compiles would need to re-parse / compile
> the same script even if the isolate had already seen it. This CL
> fixes this.
>
> Also refactors the compilation pipelines to ensure we call debug->OnAfterCompile()
> for all script compiles even when loading from a cache.
>
> BUG=v8:5203
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
>
> Change-Id: I0a74c5b67bfaca5e50511d5f72da0ab53d8457f6
> Reviewed-on: https://chromium-review.googlesource.com/937724
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51594}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,mythria@chromium.org
Change-Id: I784b9eeff75a677b9f2276fa05a0d1af09772baa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5203
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/939401
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51596}
Previously GetSharedFunctionInfoForStreamedScript didn't either check the
compilation cache or put the result of compilation into the compilation
cache. This would mean future compiles would need to re-parse / compile
the same script even if the isolate had already seen it. This CL
fixes this.
Also refactors the compilation pipelines to ensure we call debug->OnAfterCompile()
for all script compiles even when loading from a cache.
BUG=v8:5203
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0a74c5b67bfaca5e50511d5f72da0ab53d8457f6
Reviewed-on: https://chromium-review.googlesource.com/937724
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51594}
We already cleanup these scripts on frontend side. It is crucial to
cleanup them on backend side as well, since some web applications use
following logic: get some data from network, add this data to buffer,
try to parse buffer using JSON.parse. On each unsuccessfull JSON.parse
we get another scriptFailedToParse event.
Frontend logic of discarding scripts: https://goo.gl/FDtaWK
Some idea of smarter logic here: track what script ids are reported
using protocol and cleanup only script ids which reported not only as
part of scriptFailedToParse event.
R=alph@chromium.org
Bug: chromium:810812
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ifd67764c232e4abc7dc6e8e69a651bf9ac0e381b
Reviewed-on: https://chromium-review.googlesource.com/919834
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51337}
We used to calculate hash in completely incorrect way. We use each
forth character to calculate hash but we should use each one.
R=dgozman@chromium.org
Bug: v8:7426
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iaaa317bbf3b3ef71632735dfd069db450283b6f4
Reviewed-on: https://chromium-review.googlesource.com/909586
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51191}
Instead of requiring the pattern that a SuspendGenerator must be
followed by a Return, make SuspendGenerator return directly. This can,
in the future, simplify some of the reasoning around generator suspends.
Change-Id: I94c0156a89dc0e1c0bc306bc57acf766f3b4deb5
Reviewed-on: https://chromium-review.googlesource.com/857463
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50748}
It was shipped in Chrome 63.
Bug: v8:5855
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icc00b8300622d1c7b5662be8ac5e425b9781f666
Reviewed-on: https://chromium-review.googlesource.com/858381
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50558}
https://github.com/tc39/ecma262/pull/988 gained concensus during the
september 2017 TC39 meetings. This moves the load of the "next" method
to the very beginning of the iteration protocol, rather than during
each iteration step.
This impacts:
- yield*
- for-of loops
- spread arguments
- array spreads
In the v8 implementation, this also affects async iteration versions of
these things (the sole exception being the Async-From-Sync iterator,
which requires a few more changes to work with this, likely done in a
followup patch).
This change introduces a new AST node, ResolvedProperty, which can be used
as a callee by Call nodes to produce the same bytecode as Property calls,
without observably re-loading the property. This is used in several
AST-desugarings involving the iteration protocol.
BUG=v8:6861, v8:5699
R=rmcilroy@chromium.orgTBR=neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
Reviewed-on: https://chromium-review.googlesource.com/857593
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50518}
This reverts commit bf4cc9ee15.
Reason for revert: Breaks windows with msvc and linux with gcc
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265
Original change's description:
> [esnext] load `iterator.next` only once at beginning of iteration
>
> https://github.com/tc39/ecma262/pull/988 gained concensus during the
> september 2017 TC39 meetings. This moves the load of the "next" method
> to the very beginning of the iteration protocol, rather than during
> each iteration step.
>
> This impacts:
>
> - yield*
> - for-of loops
> - spread arguments
> - array spreads
>
> In the v8 implementation, this also affects async iteration versions of
> these things (the sole exception being the Async-From-Sync iterator,
> which requires a few more changes to work with this, likely done in a
> followup patch).
>
> This change introduces a new AST node, ResolvedProperty, which can be used
> as a callee by Call nodes to produce the same bytecode as Property calls,
> without observably re-loading the property. This is used in several
> AST-desugarings involving the iteration protocol.
>
> BUG=v8:6861, v8:5699
> R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
> Reviewed-on: https://chromium-review.googlesource.com/687997
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50452}
TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org
Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6861, v8:5699
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/857616
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50454}
https://github.com/tc39/ecma262/pull/988 gained concensus during the
september 2017 TC39 meetings. This moves the load of the "next" method
to the very beginning of the iteration protocol, rather than during
each iteration step.
This impacts:
- yield*
- for-of loops
- spread arguments
- array spreads
In the v8 implementation, this also affects async iteration versions of
these things (the sole exception being the Async-From-Sync iterator,
which requires a few more changes to work with this, likely done in a
followup patch).
This change introduces a new AST node, ResolvedProperty, which can be used
as a callee by Call nodes to produce the same bytecode as Property calls,
without observably re-loading the property. This is used in several
AST-desugarings involving the iteration protocol.
BUG=v8:6861, v8:5699
R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
Reviewed-on: https://chromium-review.googlesource.com/687997
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50452}
We should not report promise created for async function as candidate
for stepping. Regular StepInto works fine in this case.
TBR=dgozman@chromium.org
Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I8dafec5417df0de593cb2a1c06d6a11093e7c64b
Reviewed-on: https://chromium-review.googlesource.com/828024
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50176}
This is a reland of c3bd741efd
Original change's description:
> Fix "this" value in lazily-parsed module functions.
>
> When preparsing top-level functions in a module, we didn't track
> unresolved variables. Consequently, "this" ended up referencing
> the global "this", which has the wrong value (in a module "this"
> is supposed to be the undefined value).
>
> This patch fixes that. This also lets us stop forcing context
> allocation of all variables in module scopes, which the patch
> takes care of as well.
>
> Bug: chromium:791334
> Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
> Reviewed-on: https://chromium-review.googlesource.com/808938
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50025}
TBR=adamk@chromium.orgTBR=kozyatinskiy@chromium.org
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Bug: chromium:791334
Change-Id: I57acc7b84a345565b36cbb55924fa2ff9b449eec
Reviewed-on: https://chromium-review.googlesource.com/822341
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50045}
This reverts commit c3bd741efd.
Reason for revert: Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/20384
Original change's description:
> Fix "this" value in lazily-parsed module functions.
>
> When preparsing top-level functions in a module, we didn't track
> unresolved variables. Consequently, "this" ended up referencing
> the global "this", which has the wrong value (in a module "this"
> is supposed to be the undefined value).
>
> This patch fixes that. This also lets us stop forcing context
> allocation of all variables in module scopes, which the patch
> takes care of as well.
>
> Bug: chromium:791334
> Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
> Reviewed-on: https://chromium-review.googlesource.com/808938
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50025}
TBR=adamk@chromium.org,marja@chromium.org,neis@chromium.org,kozyatinskiy@chromium.org
Change-Id: I81f69334ed2ce104c00e6205d50001e4bdf07d15
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:791334
Reviewed-on: https://chromium-review.googlesource.com/822258
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50036}
When preparsing top-level functions in a module, we didn't track
unresolved variables. Consequently, "this" ended up referencing
the global "this", which has the wrong value (in a module "this"
is supposed to be the undefined value).
This patch fixes that. This also lets us stop forcing context
allocation of all variables in module scopes, which the patch
takes care of as well.
Bug: chromium:791334
Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
Reviewed-on: https://chromium-review.googlesource.com/808938
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50025}
If we have several scripts with the same url (see many <script> tags in
one page), then we try to set breakpoint only in script with given
lineNumber inside and ignore all other scripts. We should follow the
same logic when we capture hint for later breakpoint restore.
R=yangguo@chromium.org
Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I44a332ac64f62ec9a0d24d5fe4688f8ced125e39
Reviewed-on: https://chromium-review.googlesource.com/821053
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50019}
It will help us to preserve some scripts for user.
R=alph@chromium.orgTBR=jgruber@chromium.org
Bug: chromium:655701
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I6d42434148c2d9eb41c3a2af906e8c14ccf8d9a9
Reviewed-on: https://chromium-review.googlesource.com/806741
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49913}
Some embedders primitive can trigger execution in current JavaScript
instance or in another (e.g. MessageChannel).
With this CL external async task can be local as well.
R=dgozman@chromium.org
Bug: chromium:661705
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I82c68a021c2c25bc67a706c4bfed8c1a2b2388c5
Reviewed-on: https://chromium-review.googlesource.com/792015
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49728}
If async stack is longer then max depth, we add externalParent as id,
client can fetch next max depth async stacks by Debugger.getStackTrace.
R=dgozman@chromium.org
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I89d461e672251f03fb239f4f16ae3b0374fce766
Reviewed-on: https://chromium-review.googlesource.com/776242
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49595}
If protocol client needs to make step-into async call:
- pause before async call using any Debugger agent capabilities,
- call Debugger.stepInto with breakOnAsyncCall flag,
- wait for Debugger.paused event, this event will contain
asyncCallStackTrace if async call is scheduled,
- call Debugger.pauseOnAsyncCall on each known target,
- resume execution in current debugger by Debugger.resume.
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I40c56278e7b1ceafc3bf81608b8ca6716c2b3168
Reviewed-on: https://chromium-review.googlesource.com/773573
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49594}
Sometimes we need to capture stack trace on one debugger and use it
later as a parent stack on another debugger (e.g. worker.postMessage).
This CL includes following addition to our protocol and v8-inspector.h:
- added Runtime.StackTraceId, this id represents stack trace captured
on debugger with given id,
- protocol client can fetch Runtime.StackTrace by
Runtime.StacKTraceId using Debugger.getStackTrace method,
- externalParent field is added to Debugger.paused event, it may
contain external parent stack trace,
- V8Inspector::storeCurrentStackTrace captures current stack trace
and returns V8StackTraceId for embedder this id can be used as
argument for V8Inspector::externalAsyncTaskStarted and
V8Inspector::externalAsyncTaskFinished method. Any async stack
trace captured between these calls will get passed external stack
trace as external parent. These methods are designed to be called
on different debuggers. If async task is scheduled and started on
one debugger user should continue to use asyncTask* API,
- Debugger.enable methods returns unique debuggerId.
TBR=dgozman@chromium.org,jgruber@chromium.org
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4
Reviewed-on: https://chromium-review.googlesource.com/786274
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49591}
This reverts commit 3a41b697cd.
Reason for revert: Break msvc: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/250
Original change's description:
> [inspector] introduced stackTraceId and externalAsyncTask API
>
> Sometimes we need to capture stack trace on one debugger and use it
> later as a parent stack on another debugger (e.g. worker.postMessage).
>
> This CL includes following addition to our protocol and v8-inspector.h:
> - added Runtime.StackTraceId, this id represents stack trace captured
> on debugger with given id,
> - protocol client can fetch Runtime.StackTrace by
> Runtime.StacKTraceId using Debugger.getStackTrace method,
> - externalParent field is added to Debugger.paused event, it may
> contain external parent stack trace,
> - V8Inspector::storeCurrentStackTrace captures current stack trace
> and returns V8StackTraceId for embedder this id can be used as
> argument for V8Inspector::externalAsyncTaskStarted and
> V8Inspector::externalAsyncTaskFinished method. Any async stack
> trace captured between these calls will get passed external stack
> trace as external parent. These methods are designed to be called
> on different debuggers. If async task is scheduled and started on
> one debugger user should continue to use asyncTask* API,
> - Debugger.enable methods returns unique debuggerId.
>
> Bug: chromium:778796
> Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539
> Reviewed-on: https://chromium-review.googlesource.com/754183
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49582}
TBR=dgozman@chromium.org,pfeldman@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,jgruber@chromium.org
Change-Id: I9b52354fa0841e5148596cf594317f2e5fe508ea
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/786152
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49584}
Sometimes we need to capture stack trace on one debugger and use it
later as a parent stack on another debugger (e.g. worker.postMessage).
This CL includes following addition to our protocol and v8-inspector.h:
- added Runtime.StackTraceId, this id represents stack trace captured
on debugger with given id,
- protocol client can fetch Runtime.StackTrace by
Runtime.StacKTraceId using Debugger.getStackTrace method,
- externalParent field is added to Debugger.paused event, it may
contain external parent stack trace,
- V8Inspector::storeCurrentStackTrace captures current stack trace
and returns V8StackTraceId for embedder this id can be used as
argument for V8Inspector::externalAsyncTaskStarted and
V8Inspector::externalAsyncTaskFinished method. Any async stack
trace captured between these calls will get passed external stack
trace as external parent. These methods are designed to be called
on different debuggers. If async task is scheduled and started on
one debugger user should continue to use asyncTask* API,
- Debugger.enable methods returns unique debuggerId.
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539
Reviewed-on: https://chromium-review.googlesource.com/754183
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49582}
Old instrumentation was designed to collect promise creation stack and
promise scheduled stack together. In DevTools for last 6 months we
show only creation stack for promises. We got strong support from users
for new model. Now we can drop support for scheduled stacks and
simplify implementation.
New promise instrumentation is straightforward:
- we send kDebugPromiseThen when promise is created by .then call,
- we send kDebugPromiseCatch when promise is created by .catch call,
- we send kDebugWillHandle before chained callback and kDebugDidHandle
after chained callback,
- and we send separate kDebugAsyncFunctionPromiseCreated for internal
promise inside async await function.
Advantages:
- we reduce amount of captured stacks (we do not capture stack for
promise that constructed not by .then or .catch),
- we can consider async task related to .then and .catch as one shot
since chained callback is executed once,
- on V8 side we can implement required instrumentation using only
promise hooks,
Disadvantage:
- see await-promise test, sometimes scheduled stack was useful since we
add catch handler in native code,
Implementation details:
- on kInit promise hook we need to figure out why promise was created.
We analyze builtin functions until first user defined function on
current stack. If there is kAsyncFunctionPromiseCreate function then
we send kDebugAsyncFunctionPromiseCreated event. If there is
kPromiseThen or kPromiseCatch then only if this function is bottom
builtin function we send corresponded event to inspector. We need it
because Promise.all internally calls .then and in this case we have
Promise.all and Promise.then on stack at the same time and we do not
need to report this internally created promise to inspector.
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47
Reviewed-on: https://chromium-review.googlesource.com/765208
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49553}
We need to throw before rethrowing, otherwise the exception does
not trigger a debugger event and is not reported if uncaught.
R=gsathya@chromium.org, jgruber@chromium.org
Bug: v8:7047
Change-Id: I7ce0253883a21d6059e4e0ed0fc56dc55a0dcba6
Reviewed-on: https://chromium-review.googlesource.com/758372
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49237}
It is preparation step for step-into-worker. There are few changes:
- added breakOnAsyncCall flag for Debugger.stepInto. When flag is set
and async task is scheduled before step-into finished, we pause
execution with additional Debugger.paused event. This event contains
additional scheduledAsyncTaskId field.
- added Debugger.pauseOnAsyncTask. This method will pause execution as
soon as given async task is started.
This mechanism is replacement for Debugger.scheduleStepIntoAsync which
can not be used between multiple targets.
As result we can split async task scheduling in one target and
requesting break for this async task running in another target.
R=pfeldman@chromium.org
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I77be0c880d91253d333c54a23a4c084e7b8549e9
Reviewed-on: https://chromium-review.googlesource.com/750071
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49127}
DebugBreak bytecode fetches current return value from debugger prior
dispatching original handler. So we can change its value on break.
R=leszeks@chromium.org,rmcilroy@chromium.org
Bug: chromium:656150
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I82d0bc82ff49923a748c0084d252d0fd214a2db8
Reviewed-on: https://chromium-review.googlesource.com/731679
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49122}
Currently we incorrectly show global object as arrow function receiver.
With this CL:
- if this is used inside of function we show correct this value,
- if this is unused and V8 optimizes it out - we show undefined.
Second is known issue which we should address separately.
R=dgozman@chromium.org,yangguo@chromium.org
Bug: chromium:552753
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iac88a07fe622eb9b2f8af7ecbc4a32a56c8cdfaa
Reviewed-on: https://chromium-review.googlesource.com/723840
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48839}
This is a reland of 61292f0b60
Original change's description:
> [inspector] breakpoint after last break position should not jump to first line
>
> R=jgruber@chromium.org
>
> Bug: chromium:730177
> Change-Id: I0f3666a333604cb80bb51410c5edf2aceb0c6ef5
> Reviewed-on: https://chromium-review.googlesource.com/717717
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48556}
TBR=jgruber@chromium.org
Bug: chromium:730177
Change-Id: I564cc5d7778f9d79780eae9dbe2d9aafaad4f466
Reviewed-on: https://chromium-review.googlesource.com/721468
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48615}
Use case: anonymous script with sourceMappingUrl. User can set
breakpoint in source with sourceUrl from sourceMap, we persist this
breakpoint in DevTools and on page reload breakpoint should be restored
correctly.
Debugger.setBreakpointByUrl method provides capabilities to set
provisional breakpoints and looks like best candidate for new "scriptHash"
argument.
I considered other options such as replacing scriptId with something
more persistent like "script-hash:script-with-this-hash-number" but it
looks more complicated and doesn't provide clear advantages.
One pager: http://bit.ly/2wkRHntR=pfeldman@chromium.org
Bug: chromium:459499
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I0e2833fceffe6b04afac01d1a4522d6874b6067a
Reviewed-on: https://chromium-review.googlesource.com/683597
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48357}
Before we used to require compiled debugger script to report Scopes.
After migration inspection to brand-new native API we can report
Scopes all the time and remove this hidden dependency.
R=dgozman@chromium.org
Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I3530bc7ead691a51073e384aea4a4ef428dc94da
Reviewed-on: https://chromium-review.googlesource.com/662097
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47982}
Runtime.CallFrame has url already. It allows to show stack traces on pause
without tacking all parsed scripts.
R=alph@chromium.org,pfeldman@chromium.org
Bug: chromium:762982
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ic4f096ade1cb6c9de42fec77280dcc3007c6a5cf
Reviewed-on: https://chromium-review.googlesource.com/648068
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47895}
Currently, injected script source adds natural object properties before
internal properties. This can result in important ones such as
"[[PrimitiveValue]]" being left out. This CL
- makes sure internal properties are always added to preview
- removes unused "[[Iterator*]]" properties from preview
- boxed strings (e.g. new String("foo")) will not send unnecessary
properties 0:"f", 1:"o", 2:"o" if the [[PrimitiveValue]] is sent.
Bug: chromium:567265
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Icd5c7410351f371055277ce471226cc6fb5a861f
Reviewed-on: https://chromium-review.googlesource.com/634584
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Erik Luo <luoe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47622}
This is a reland of 21da12a983
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=yangguo@chromium.orgTBR=jarin@chromium.org
Bug: v8:6409
Change-Id: If2eae66a85f129e746a5ca5c04935540f3f86b04
Reviewed-on: https://chromium-review.googlesource.com/618886
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47399}
This reverts commit 21da12a983.
Reason for revert: Failing on arm64 simulator
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,leszeks@chromium.org
Change-Id: I4ba63e82417a185f1528ff2633eb6c8872fbbfe5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6409
Reviewed-on: https://chromium-review.googlesource.com/618687
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47397}
Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
function. The code in compiler.cc is refactored to use this function to compile
the SharedFunctionInfo when compiling a JSFunction.
Also does some other cleanup:
- Removes CompileUnoptimizedFunction and inlines into new Compiler function
- Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
out of FinalizeUnoptimizedCompile.
BUG=v8:6409
Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
Reviewed-on: https://chromium-review.googlesource.com/613760
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47394}
As long as we have scripts with negative source offset (see inline event listeners) we should not crash a browser when get negative offset.
R=jgruber@chromium.org
Bug: chromium:750592
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ic3138e7c61ec0a5133c56de9970acdffa5536d8e
Reviewed-on: https://chromium-review.googlesource.com/611613
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47318}
This changes the baseline of an inspector test setting breakpoints
within an asm.js module while the module is being executed. With the
validator it is not supported to switch from active WebAssembly code
back to debuggable interpreter code. Hence some previously expected
breakpoints no longer fire, the behavior is consistent across all
configurations now though.
R=yangguo@chromium.org
TEST=inspector/debugger/asm-js-breakpoint-during-exec
BUG=v8:6166
Change-Id: Ie1bb62fa6df28b10336b4cb5d381d2141eec356c
Reviewed-on: https://chromium-review.googlesource.com/608977
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47301}
This is in preparation to the removal of the FullCodeGenerator, we no
longer need the ability to stress the underlying implementation.
R=rmcilroy@chromium.org
BUG=v8:6409
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Iad3177d6de4a68b57c12a770b6e85ed7a9710254
Reviewed-on: https://chromium-review.googlesource.com/584747
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47276}
Original intention of longScript was to check how hashing works with long
script source. Current implementation calculates hash for longString function,
it's non reliable since Function.toString is still not specified and can return
different line endings on different architectures.
TBR=dgozman@chromium.org
Bug: none
Change-Id: I4c5b6f30c2849a1a2702c74665b86ced731f1b28
Reviewed-on: https://chromium-review.googlesource.com/609486
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47268}
This call from inspector side is redundant, V8 will clear all breakpoints on removing debug delegate in v8::internal::Debug::Unload method.
In any case for correct support of multiclient we need to clear breakpoints in V8DebuggerAgentImpl::disable method.
R=dgozman@chromium.org
Bug: v8:5510,chromium:652939
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I66f9b97797860bad28884a099928d54ac3560428
Reviewed-on: https://chromium-review.googlesource.com/592281
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47022}
To avoid using debugging context and debugger-script.js on inspector side we can move SetScriptSource call to v8::internal::Debug. Theoretically we can move live edit implementation to native completely but since it will be reimplemented it looks redundant.
R=yangguo@chromium.org,jgruber@chromium.org
Bug: chromium:652939
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id09492c2d2a93efbde429c9cc1bc181d5fdda19b
Reviewed-on: https://chromium-review.googlesource.com/590736
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46985}
This CL moves us much closer to the point where we can remove debugger-script.js and usage of debugger context from inspector.
There are three main parts left:
- managing breakpoints,
- inspecting stack and scopes (this CL),
- LiveEdit.
In this CL I moved all stack/scope inspection to native. As side effect running debugger and inspector tests are 10-20% faster (it's significant since not all of tests requesting break).
R=yangguo@chromium.org,jgruber@chromium.org
Bug: chromium:652939
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I409396a687e18e9c0554c0c9c35b6e1064627be8
Reviewed-on: https://chromium-review.googlesource.com/580645
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46947}
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/543161
Reviewed-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}
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}
This includes several changes. From most to least interesting:
- No longer implement AwaitExpressions using a do-expression.
- Reduces frame-size of async generators by not allocating temporary
variables to hold results of Await epxressions.
- Streamline and reduce generated bytecodes for Await.
- Debugger no longer emits a debug::kCallBreakLocation breakpoint for
the JS-builtin call performed for Await, and instead only emits such
a breakpoint if the operand of Await is actually a call.
- Push fewer parameters to Await* builtins, using the receiver for the
first parameter (possible now that the CallRuntime invocation not
part of the AST).
- Adds a new Await AST node. No new members or anything, but it seemed
palatable to avoid having `if (is_await())` in a number of
VisitSuspend functions.
BUG=v8:5855, v8:5099, v8:4483
R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.orgTBR=bmeurer@chromium.org
Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf
Reviewed-on: https://chromium-review.googlesource.com/558806
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46666}
Removes the --ignition flag which is now on by default. Adds a
--stress-fullcodegen flag which enables running all functions supported
by fullcodegen to be compiled by fullcodegen.
This will enable moving parser internalization later when we are not
stressing fullcodegen or compiling asm.js functions.
BUG=v8:5203, v8:6409, v8:6589
Change-Id: I7fa68016d4e734755434ec0b4e749ef65ffa7f4e
Reviewed-on: https://chromium-review.googlesource.com/565569
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46635}
When providing scope information (containing the value of local
variables of live stack frames), decode the local variable names of all
functions in a wasm module and store this in the WasmDebugInfo
structure.
Use these names to actually name the reported locals, instead of using
the default names "param#<d>" and "local#<d>". These names are only used
as fallbacks for locals which were not assigned a name.
R=titzer@chromium.org,kozyatinskiy@chromium.org
BUG=v8:6245
Change-Id: Ibf7d30e392248ef5590177cd8b6329239b45e018
Reviewed-on: https://chromium-review.googlesource.com/548495
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46379}
This removes the --turbo flag and solely relies on the filter pattern
provided via --turbo-filter when deciding whether to use TurboFan. Note
that disabling optimization wholesale can still be done with --no-opt,
which should be used in favor of --no-turbo everywhere.
Also note that this contains semantic changes to the TurboFan activation
criteria. We respect the filter pattern more stringently and no longer
activate TurboFan just because the source contains patterns forcing use
of Ignition via {AstNumberingVisitor::DisableFullCodegenAndCrankshaft}.
R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I0c855f6a62350eb62283a3431c8cc1baa750950e
Reviewed-on: https://chromium-review.googlesource.com/528121
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46167}
This CL removes most occurences of "WASM" from outputs and comments in
the code. They are replaced either by "WebAssembly" or (especially in
comments) "wasm". These are the spellings officially proposed on
http://webassembly.org/.
R=ahaas@chromium.org
BUG=v8:6474
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id39fa5e25591678263745a4eab266db546e65983
Reviewed-on: https://chromium-review.googlesource.com/529085
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45824}
Both Ignition and TurboFan have been enabled by default for a while.
This just disentangles the implication between those two flags and sets
the --ignition individually. They can now be controlled individually.
R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I08eca85120160efa5868b5ca36d1613964ed82eb
Reviewed-on: https://chromium-review.googlesource.com/527637
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45800}
BytecodeArrayBreakIterator doesn't iterate through locations in position() order. SkipToPosition is looking for closest break_index to passed one. So we should iterate through all breakable locations in function to get all of them.
R=jgruber@chromium.org
Bug: v8:6469
Change-Id: Ida0b849e9df40458a13e0a0f7af6a00349088228
Reviewed-on: https://chromium-review.googlesource.com/527135
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45765}
This patch adds ability to connect multiple sessions to a single context group. This is an experimental feature, which is already supported in test harness.
So far covered runtime domain with tests (and found a bug thanks to the test). More tests to follow in next patches, probably with code adjustments as well.
BUG=chromium:590878
Review-Url: https://codereview.chromium.org/2906153002
Cr-Commit-Position: refs/heads/master@{#45667}
V8 provides ScriptCompiler::CompileFunctionInContext method which takes expression and compile it as anonymous function like (function() .. expression ..). To produce correct locations for stmts inside of this expression V8 compile this function with negative offset. Instead of stmt position blackboxing use function start position which is negative in described case.
Bug: chromium:705963
Change-Id: I86b113198fb59e77b3bbf523c8cd943e22f8a6ca
Reviewed-on: https://chromium-review.googlesource.com/519384
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45637}
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/514046
Reviewed-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}
This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
Benefits (see test for details):
- only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
- removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.
TBR=dgozman@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org,devtools-reviews@chromium.org,v8-reviews@googlegroups.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:5909
Change-Id: Ie84fa79afeed09e28cf8478ba610a0cfbfdfc294
Reviewed-on: https://chromium-review.googlesource.com/518116
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45598}
This reverts commit 7a9cc70492.
Reason for revert: Changes layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/15882
This is about:
inspector/sources/debugger/source-frame-inline-breakpoint-decorations.html
Original change's description:
> [inspector] moved var initialization break location before init expression
>
> This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
> Benefits (see test for details):
> - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
> - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.
>
> Bug: v8:5909
> Change-Id: I039d911903a2826c9859710a63ab0462c992e11b
> Reviewed-on: https://chromium-review.googlesource.com/513926
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45530}
TBR=dgozman@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:5909
Change-Id: Ibf84401e8050d3c84db219d983de2c6bba0f697f
Reviewed-on: https://chromium-review.googlesource.com/518102
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45547}
This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
Benefits (see test for details):
- only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
- removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.
Bug: v8:5909
Change-Id: I039d911903a2826c9859710a63ab0462c992e11b
Reviewed-on: https://chromium-review.googlesource.com/513926
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45530}
In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume.
The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change.
I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit.
Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish.
BUG=v8:6368
Review-Url: https://codereview.chromium.org/2898163002
Cr-Commit-Position: refs/heads/master@{#45515}
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}
This refactoring makes it easier to write advanced tests and
gives full control over what's happening to the test code.
It also forces description for every test.
BUG=none
Review-Url: https://codereview.chromium.org/2891213002
Cr-Commit-Position: refs/heads/master@{#45412}
- moved all extensions to inspector_test.cc;
- properly supported multiple context groups and sessions;
- better isolation between components;
- better infrastructure in protocol-test.
BUG=chromium:590878
Review-Url: https://codereview.chromium.org/2890463004
Cr-Commit-Position: refs/heads/master@{#45409}
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
98927ea51b, as the test failure
due to that change was a code flushing bug. Code flushing was
disabled in de4a4095cf.
R=rmcilroy@chromium.org
Bug: v8:6379
Change-Id: Ifb4deafea99693c0a4e8646cf4e9884c7374cfc6
Reviewed-on: https://chromium-review.googlesource.com/508814
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45406}
By default we just break when we first time reach passed location, with current - we'll break at passed location only when it happens within the same stack frame.
BUG=v8:6397
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2879923003
Cr-Commit-Position: refs/heads/master@{#45354}
This reverts commit 98927ea51b.
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/506548
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45319}
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}
Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved.
For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same.
BUG=v8:6189
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2868493002
Cr-Original-Commit-Position: refs/heads/master@{#45198}
Committed: e118462f18
Review-Url: https://codereview.chromium.org/2868493002
Cr-Commit-Position: refs/heads/master@{#45266}
Reason for revert:
CHECK is too strict.
Original issue's description:
> [inspector] use creation stack trace as parent for async call chains
>
> Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved.
> For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same.
>
> BUG=v8:6189
> R=dgozman@chromium.org
>
> Review-Url: https://codereview.chromium.org/2868493002
> Cr-Commit-Position: refs/heads/master@{#45198}
> Committed: e118462f18TBR=dgozman@chromium.org,alexclarke@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:6189
Review-Url: https://codereview.chromium.org/2868423004
Cr-Commit-Position: refs/heads/master@{#45242}
Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved.
For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same.
BUG=v8:6189
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2868493002
Cr-Commit-Position: refs/heads/master@{#45198}
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}
getPossibleBreakpoints implementation can enforce function compilation which potentially can produce syntax error, we need to have a context to correctly report this error.
BUG=chromium:715334
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2851853002
Cr-Commit-Position: refs/heads/master@{#45003}
- we should always set creation async stack if it's available regardless existing of current parent async stack,
- we should cleanup parent link iff there is no creation and schedule async stack for parent.
Let's consider example: Promise.resolve().then(x => x).then(x => x), there is three promises which will call following instrumentation:
1) created #1 (Promise.resolve()) - collected stack #1
2) scheduled #1 - collected stack #2
3) created #2 with #1 as parent (first .then) - collected stack #3
4) created #3 with #2 as parent (first .then) - collected stack #4
5) started #2 - use stack #2 as scheduled
6) scheduled #2 - collected stack #6
7) finished #2
8) started #3 - use stack #6 as scheduled
9) scheduled #3 - collected stack #7
10) finished #3
If we collect stacks between step 4 and 5, it's possible to collect scheduled stack #2 but still have creation stack for #2 - stack #3 - so we always need to add creation event if scheduled is collected.
If we collect stacks between created and scheduled we should not remove parent link even if parent was not scheduled yet.
BUG=v8:6189
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2844753002
Cr-Commit-Position: refs/heads/master@{#44990}
.. replace all of them with prepared global object template.
+ bonus: wrap inspector related methods with inspector namespace.
BUG=none
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2832723004
Cr-Commit-Position: refs/heads/master@{#44785}
With recent CLs we always store maximum N async stack traces and when we reach limit we drop half of them.
Current promise collected event requires creating weak handle:
- it takes time,
- it consumes memory.
Since async task id distribution for promises is uniform (each new promise has last_async_task_id + 1 as an id) our hash map is good enough to handle any amount of async task ids, following time of executing 1 000 000 000 of lookups:
- for empty hash map: 1.45 seconds,
- for hash map with one entry: 14.95 seconds
- 1024 entries: 15.03 seconds
- 1024 * 1024 entries: 14.82 seconds
- 1024 * 1024 * 1024: 17.9 seconds
BUG=v8:6189
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2819423005
Cr-Commit-Position: refs/heads/master@{#44750}
- separated V8StackTraceImpl and AsyncStackTrace,
- V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned),
- V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces.
- async tasks are cleared with related async stacks.
BUG=v8:6189
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2816043006
Cr-Original-Commit-Position: refs/heads/master@{#44670}
Committed: 1bca73bc83
Review-Url: https://codereview.chromium.org/2816043006
Cr-Commit-Position: refs/heads/master@{#44694}
Reason for revert:
Speculative revert. Seems to block the roll:
https://codereview.chromium.org/2822983004/
Might require changing a browser test first?
Original issue's description:
> [inspector] avoid cloning of async call chains
>
> - separated V8StackTraceImpl and AsyncStackTrace,
> - V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned),
> - V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces.
> - async tasks are cleared with related async stacks.
>
> BUG=v8:6189
> R=dgozman@chromium.org
>
> Review-Url: https://codereview.chromium.org/2816043006
> Cr-Commit-Position: refs/heads/master@{#44670}
> Committed: 1bca73bc83TBR=dgozman@chromium.org,kozyatinskiy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6189
Review-Url: https://codereview.chromium.org/2825713002
Cr-Commit-Position: refs/heads/master@{#44678}
- separated V8StackTraceImpl and AsyncStackTrace,
- V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned),
- V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces.
- async tasks are cleared with related async stacks.
BUG=v8:6189
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2816043006
Cr-Commit-Position: refs/heads/master@{#44670}
This CL implements the proposed change to show information about
WebAssembly values and call frames via the inspector interface.
Each interpreted WebAssembly frame will have two scopes: A global scope
showing information about the memory (to be extended for globals), and
a local scope showing information about parameters, local variables, and
stack values.
Names of local variables will be added later.
R=ahaas@chromium.org, yangguo@chromium.org
BUG=v8:6245,v8:5822
Change-Id: I0a35fddd0a353933c86adf62083233b08098a2c7
Reviewed-on: https://chromium-review.googlesource.com/474865
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44633}
The format of the name section changed recently. It now contains
subsections of different type (currently for function names or local
variable names).
This CL changes our internal wasm module builders (in JS and C++) to
emit this new format, and changes the decoder to understand it.
We currently only parse the function name section, and ignore names of
local variables. I will later extend this to parse local variable names
when needed for debugging.
R=ahaas@chromium.org, rossberg@chromium.org
BUG=v8:6222
Change-Id: I2627160c25c9209a3f09abe0b88941ec48b24434
Reviewed-on: https://chromium-review.googlesource.com/470247
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44492}
With flag we can debug injected-script-source in inspector-test or from DevTools frontend as regular user code. We need this when working on new features or debugging issues, it's for internal purpose only and doesn't provide any benefits for end users.
Flag: --expose-inspector-scripts
BUG=none
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2767873002
Cr-Commit-Position: refs/heads/master@{#44039}
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}
Proposed behaviour:
- StepNext at return position go into next function call (no changes with current behavior, but implemented in v8::Debug instead of hack on inspector side);
- StepOut at return position go into next non-current function call.
We need this to have better stepping in cases with native functions, blackboxed functions and/or different embedder calls (e.g. event listeners).
New behavior could be illustrated with two examples (for more see stepping-with-natives-and-frameworks test):
- let's assume that we've blackboxed callAll function, this function just takes its arguments and call one after another:
var foo = () => 1;
callAll(foo, foo, () => 2);
If we break inside of first call of function foo. Then on..
..StepNext - we're able to reach second call of function foo,
..StepOut - we're able to reach () => 2 call.
- let's consider case with native function:
[1,2,3].map(x => x * 2)
If we break inside of first callback call, then with StepNext we can iterate through all calls of callback, with StepOut we go to next statement after .map call.
Implementation details:
- when we request break we schedule step-in function call for any step action at return position and for step-in at any position,
- when we request StepOut at return position - we mark current function as needed-to-be-ignored inside of PrepareStepIn(function) call,
- when we request StepOut at not return position - we set break at return position and ask debugger to just repeat last step action on next stepping-related break.
Design doc: https://docs.google.com/document/d/1ihXHOIhP_q-fJCA0e2EiXz_Zr3B08KMjaPifcaqZ60Q/edit
BUG=v8:6118,chromium:583193
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2758483002
Cr-Commit-Position: refs/heads/master@{#44028}
In Isolate::CaptureSimpleStackTrace, we were ignoring interpreter entry
frames so far. This CLs changes this to gets the interpreted stack from
the wasm interpreter and add the frames to the FrameArray.
R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822
Change-Id: I705909532ff28af412ff809da94522866eaa1c0d
Reviewed-on: https://chromium-review.googlesource.com/452378
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43772}
We emulate break by callling breakProgramCallback function in debugger context, we can just use HandleDebugBreak.
It allows us to move all stepping logic to debug.cc later and remove one usage of debugger context.
+ two minor issues fixed, see tests.
BUG=v8:5510
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2738503006
Cr-Commit-Position: refs/heads/master@{#43750}
Add a mechanic to set these Builtin exception predictions per-Isolate
rather than per-Context in the Bootstrapper.
Also add Debugger tests which would fail without these prediction
modes set.
Does not yet test for AsyncFromSyncIteratorPrototypeReturn, as this
requires AsyncGenerators and `yield*` to be hit.
BUG=chromium:691875
R=yangguo@chromium.org, jgruber@chromium.org, gsathya@chromium.org
Change-Id: Ic2d2aba3870cce2f7321080f4278875edf253c76
Reviewed-on: https://chromium-review.googlesource.com/451967
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#43742}
Once we enabled --turbo by default we need to turn all the implications
off with --no-turbo as well. Chrome sets flags in V8 using SetFlagFromString,
which enforces the implications each time it is called. Therefore, if --turbo
is enabled by default, and an unrelated flag is set, the turbo implications are
enabled but not later disabled if we set --no-turbo. To fix this, add negative
implications as well.
BUG=chromium:692409
Change-Id: Iadb0ca542f49ba65c7419cda8c7a03636a8d5ba9
Reviewed-on: https://chromium-review.googlesource.com/451320
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43655}
This CL provide type with each break location, type could be: call, return or debugger statement.
BUG=chromium:432469
R=yangguo@chromium.org,dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2728563002
Cr-Commit-Position: refs/heads/master@{#43619}
This method could be called on pause and will do stepInto next scheduled callback if any will happen until next break.
First implementation support only callbacks chained by Promise.prototype.then.
BUG=chromium:432469
R=yangguo@chromium.org,dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2723273002
Cr-Commit-Position: refs/heads/master@{#43616}
If the imported wasm function is being debugged (i.e. redirects to the
interpreter), call it via the JS_TO_WASM stub, such that we can disable
the breakpoint later by patching the exported function.
This also contains a drive-by fix in wasm-translation.cc (for the case
that all known positions are bigger than the requested one).
R=titzer@chromium.org, kozyatinskiy@chromium.org
BUG=v8:5971, v8:5822
Review-Url: https://codereview.chromium.org/2720813002
Cr-Commit-Position: refs/heads/master@{#43583}
With inline breakpoints DevTools are ready for break position aligned breakpoints instead of statement aligned.
BUG=chromium:695236
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2709263002
Cr-Commit-Position: refs/heads/master@{#43385}
In current implementation we don't support nested scheduled break at all. If one break was scheduled inside another and second one doesn't produce actual break (execution was in blackboxed code or no JavaScript was executed) then second one will clear first scheduled break even if any not blackboxed JavaScript will be executed later.
Ambiguous break reason is added for the case when we have more then one scheduled reason. "auxData" in this case contains object with array of { reason: reason, auxData: auxData } objects for each reason in 'reasons' property.
BUG=chromium:632405
Review-Url: https://codereview.chromium.org/2678313002
Cr-Commit-Position: refs/heads/master@{#43021}
- entries preview available even if debugger agent is disabled,
- less deprecated mirrors usage in debugger-script.js
- no usage of debugger context - zero probability of leaking it.
- better test coverage.
BUG=v8:5510
R=yangguo@chromium.org,jgruber@chromium.org,alph@chromium.org,luoe@chromium.org
Review-Url: https://codereview.chromium.org/2672213002
Cr-Commit-Position: refs/heads/master@{#42978}
V8DebuggerAgentImpl::m_skipAllPaused is moved to V8Debugger.
V8DebuggerAgentImpl::didPaused doesn't return shouldBreak flag and called only when break is required and stack trace presented.
V8DebuggerAgentImpl doesn't store paused context.
Logic of conversion step-next at return into step-in is moved to debug.cc.
BUG=none
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2668763003
Cr-Commit-Position: refs/heads/master@{#42907}
Always execute the implicit return if we fell off the function bytes.
This is not considered an additional "step" as it is not executing a
wasm instruction.
Otherwise, we might pause at an invalid position (one after the
function bytes).
R=titzer@chromium.org
BUG=v8:5822
Review-Url: https://codereview.chromium.org/2650293003
Cr-Commit-Position: refs/heads/master@{#42730}
