- 19 Apr, 2018 1 commit
-
-
Stephan Herhut authored
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/1019302Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Stephan Herhut <herhut@chromium.org> Cr-Commit-Position: refs/heads/master@{#52691}
-
- 11 Apr, 2018 1 commit
-
-
Alexey Kozyatinskiy authored
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}
-
- 05 Apr, 2018 1 commit
-
-
Alexey Kozyatinskiy authored
This is a reland of 7a2c3713 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/996760Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#52373}
-
- 04 Apr, 2018 3 commits
-
-
Aleksey Kozyatinskiy authored
This reverts commit 7a2c3713. 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/996135Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#52371}
-
Alexey Kozyatinskiy authored
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}
-
Andrey Lushnikov authored
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}
-
- 09 Mar, 2018 1 commit
-
-
Erik Luo authored
- 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}
-
- 08 Mar, 2018 1 commit
-
-
Stephan Herhut authored
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/951303Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Stephan Herhut <herhut@chromium.org> Cr-Commit-Position: refs/heads/master@{#51801}
-
- 27 Feb, 2018 3 commits
-
-
Ross McIlroy authored
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}
-
Clemens Hammacher authored
This reverts commit 25427203. 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/939401Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51596}
-
Ross McIlroy authored
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}
-
- 20 Feb, 2018 1 commit
-
-
Yang Guo authored
R=bmeurer@chromium.org Bug: v8:7421 Change-Id: Iacdd8d294c02b7feb72e3a0bb397930e91197ae7 Reviewed-on: https://chromium-review.googlesource.com/926124 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51391}
-
- 16 Feb, 2018 2 commits
-
-
Alexey Kozyatinskiy authored
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}
-
Erik Luo authored
Bug: chromium:810176 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I330fa0bdf81d0bb926cf6db794736e89c069f8f2 Reviewed-on: https://chromium-review.googlesource.com/907707Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Erik Luo <luoe@chromium.org> Cr-Commit-Position: refs/heads/master@{#51333}
-
- 08 Feb, 2018 1 commit
-
-
Alexey Kozyatinskiy authored
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}
-
- 22 Jan, 2018 1 commit
-
-
Leszek Swirski authored
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/857463Reviewed-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}
-
- 12 Jan, 2018 1 commit
-
-
Adam Klein authored
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}
-
- 11 Jan, 2018 1 commit
-
-
Caitlin Potter authored
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 TBR=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}
-
- 09 Jan, 2018 2 commits
-
-
Michael Achenbach authored
This reverts commit bf4cc9ee. Reason for revert: Breaks windows with msvc and linux with gcc https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841 https://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/857616Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#50454}
-
Caitlin Potter authored
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}
-
- 18 Dec, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
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/828024Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50176}
-
- 14 Dec, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
Async stack trace can contain empty syncrhonous stack and external stack. R=dgozman@chromium.org Bug: chromium:790567 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I2b04743f7c4f15a038eb1041cc7fc117d438b6b2 Reviewed-on: https://chromium-review.googlesource.com/822971 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#50117}
-
- 12 Dec, 2017 4 commits
-
-
Georg Neis authored
This is a reland of c3bd741e 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 TBR=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}
-
Michael Achenbach authored
This reverts commit c3bd741e. 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/822258Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#50036}
-
Georg Neis authored
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/808938Reviewed-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}
-
Alexey Kozyatinskiy authored
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}
-
- 06 Dec, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
It will help us to preserve some scripts for user. R=alph@chromium.org TBR=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}
-
- 29 Nov, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
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}
-
- 23 Nov, 2017 2 commits
-
-
Alexey Kozyatinskiy authored
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}
-
Alexey Kozyatinskiy authored
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}
-
- 22 Nov, 2017 3 commits
-
-
Alexey Kozyatinskiy authored
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}
-
Clemens Hammacher authored
This reverts commit 3a41b697. 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/786152Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#49584}
-
Alexey Kozyatinskiy authored
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/754183Reviewed-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}
-
- 21 Nov, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
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}
-
- 08 Nov, 2017 1 commit
-
-
Yang Guo authored
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/758372Reviewed-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}
-
- 06 Nov, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
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/750071Reviewed-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}
-
- 04 Nov, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
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/731679Reviewed-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}
-
- 23 Oct, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
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}
-
- 18 Oct, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
R=dgozman@chromium.org Bug: none Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I0fa10978266feb3c3907ce1f3386ae7a34a33582 Reviewed-on: https://chromium-review.googlesource.com/726490Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#48705}
-
- 16 Oct, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
This is a reland of 61292f0b 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}
-