* Skip 8 tests that timeout due to the low-performance of current MMTk non-moving GC.
- This will be enabled after TPH performance issues are addressed.
* Skip 2 new tests that creates a second isolate -- TPH does not support it at the moment.
* Skip 1 test that expects concurrent sweeping behavior of cppgc.
Bug: v8:11641
Change-Id: If86cdcc303b01536d278368886bb30d91da5c5c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2909692
Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75036}
In the Chrome DevTools Protocol, the step actions are named StepOut,
StepOver, and StepInto, but internally we used StepOut, StepNext, and
StepIn instead. This change adjusts the naming to be consistent.
Bug: chromium:901814, chromium:1162229
Change-Id: Id3502a1b0a4aadd94734ec3d1fef73c1782fa220
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928510
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74877}
Prior to this patch, regular expression objects with a monkeypatched
`toString` were printed using the `toString` result value, rather than
actually representing the regular expression’s contents.
const re = /./;
re.toString = () => 'whoops!';
console.log(re);
// → logs 'whoops!'
Now that `v8::RegExp::GetSource` properly escapes special characters in
the source pattern [1], just like `RegExp#toString`, there is no longer
any reason to avoid it.
[1]: https://chromium-review.googlesource.com/c/v8/v8/+/2900737
Bug: v8:11693
Change-Id: I9a69cdb6813f76b669bdc24e4823c6d261f2ae73
Fixed: v8:11836
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928188
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74862}
This adds a new status file indicator "HEAVY" to mark tests with high
resource demands. There will be other tests running in parallel,
but only a limited number of other heavy tests. The limit is
controlled with a new parameter --max-heavy-tests and defaults to 1.
The change also marks a variety of tests as heavy that recently had
flaky timeouts. Heavy also implies slow, hence heavy tests are
executed at the beginning with a higher timeout like other slow tests.
The implementation is encapsulated in the test-processor chain. A
new processor buffers heavy tests in a queue and adds buffered tests
only if other heavy tests have ended their computation.
Bug: v8:5861
Change-Id: I89648ad0030271a3a5af588ecc9c43285b728d6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905767
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74712}
With this CL, V8 adds an internal field to the WebAssembly Table object
that is sent to DevTools to also show table entries. As WebAssembly
Tables get initialized lazily, V8 only shows the name of the function
instead of the function object itself.
Screenshot before change: https://imgur.com/a/XFvy3lA
Screenshot after change: https://imgur.com/kT84kstR=kimanh@chromium.org
Change-Id: I56a0b07785ff3484f1447419fe39ae5ec3f93247
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897097
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74690}
When setting a breakpoint on a line (in the DevTools front-end), the
front-end sends a columnNumber of 0 and the inspector automatically
resolves the actual location (in bytecode execution order). In order
to also support changing source code, the inspector memorizes a text
hint, and uses that to adjust the location upon reload. This hint was
however taken based on the original line and column numbers, rather than
the resolved location, which causes trouble when syntactic order doesn't
match execution order, as in case of `await o.m()`.
In order to address that we now remember the textual hint based on the
resolved location.
Fixed: chromium:1081162
Also-By: kimanh@chromium.org
Change-Id: I7d08373440693b7abc18c29c1a05929d771d3031
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905606
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74675}
This CL fixes a failed DCHECK due to incorrect heap capacity.
Also skips three new tests that create multiple isolates.
Bug: v8:11641
Change-Id: I1061b3370efbe2b272bd490705fc728d6bb26910
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2896644
Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74583}
wasm-scope-info requires SIMD, since it prints the value of the SIMD
value in scope. We skip it using statusfile when SIMD is not supported.
Change-Id: Id64e130a1c497bae95ec5e794ad05816f8c908e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2893568
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74573}
Various WebAssembly APIs that don't have observable side-effects aren't
marked as such, leading to the inability of DevTools front-end to
generate eager evaluation previews in the Console, and also making them
unusable in conditional breakpoints and logpoints.
Bug: chromium:1164241
Change-Id: I8f0675d2ed5b362b34a6f6c756d372a61e9e8564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891571
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74563}
The callback IsolateData::ModuleResolveCallback, used by the fuzzer,
can return an empty MaybeLocal.
In this case v8::internal::SourceTextModule::PrepareInstantiate expects
it to have thrown an exception, and DCHECKs.
The fuzzer can hit this case because it doesn't load the entire module
graph before starting to tell V8 to instantiate modules. So if a module
fails to compile or load, another module trying to import it will hit
this DCHECK because we didn't bail out prior to module instantiation
like we should have.
This doesn't happen in Chromium because Blink loads the entire module
graph before trying to instantiate/link modules, ensuring that the
'real' ModuleRecord::ResolveModuleCallback never fails; indeed this is
mandated by the spec (see
https://html.spec.whatwg.org/#fetch-the-descendants-of-and-link-a-module-script).
To satisfy the fuzzer, this change makes
IsolateData::ModuleResolveCallback throw if it can't find the module.
Note, the bug's testcase doesn't involve import assertions. I don't
think this issue is new with my change
9d72d08a8c
but maybe that changed the crash stack or something in a way that
caused the issue to be reported.
Bug: chromium:1207078
Change-Id: I1fbc80faa099e040cdc489c965a5f2f5daafb38e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2890589
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74526}
The HeapProfiler.startSampling method accepts a samplingInterval
parameter, which is assumed to be a positive (non-zero) number,
but doesn't validate the input (the renderer process just crashes
hard on a CHECK instead).
Fixed: chromium:1197392
Change-Id: Ib8e34f4b9881cd195214791ca0a3892e7b49bf55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891573
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74523}
The WebAssembly specification requires the "name" property of (exported)
function wrappers to hold the index of the function within the module,
and the default ToString algorithm for Function instances thus generates
something along the lines of `function 42() { [native code] }`, which is
technically correct, but not very useful to developers to diagnose
(humans don't think of functions in a module in terms of their indices).
With this CL, we change the description returned for Wasm (exported)
functions to use the debug name of the Wasm function instead.
Screenshot: https://imgur.com/a/FVPeXDU.png
Doc: http://bit.ly/devtools-wasm-entities
Fixed: chromium:1206620
Bug: chromium:1164241
Change-Id: I096abc287ea077556c13c71f8d71f64452ab4831
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891570
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74517}
Drive-by-fix: Remove command line API fn.toString() override, which was
still in place from the early days when much of the inspector was
implemented in JavaScript.
Fixed: chromium:1207867
Bug: chromium:1206620
Change-Id: I8429f109da5f021f729f184fd824160a24e60897
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2887508
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74516}
* Set v8_enable_pointer_compression_shared_cage = false for TPH.
* Skip three more tests that creates multiple isolates (which is not supported by TPH at the moment).
Bug: v8:11641
Change-Id: Iefec0ea3e2ed51e8973546441f5daaa2ac02ab57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2881510
Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74460}
This changes the names reported in stack traces via the Chrome DevTools
protocol to follow the WAT naming convention for functions. This aligns
the behavior here with the rest of DevTools (i.e. the disassembly in the
Sources panel and the Scope sidebar, as well as the Console REPL) to use
one consistent naming scheme.
Fixed: chromium:1159307
Doc: http://bit.ly/devtools-wasm-entities
Bug: chromium:1162229, chromium:1164241, chromium:1071432
Change-Id: Ibe543f39c775944072073fe5f0959412529aa19b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878734
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74456}
Our current logic for the console API's monitor implementation relies on
JavaScript's arguments array. In arrow functions, this results in an
error, resulting missing print statements from monitor.
This CL at least re-enables the print statements, but does not print the
arguments in the case of arrow functions.
Change-Id: Ibf6c2a0fb5e0cc911c257520a59a875992fe3777
Bug: chromium:1206137
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880216
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74437}
As per WebAssembly Web API[1], the engine should only consider names
from the name section to synthesize function names in the context of
call stacks. We previously also added support to harvest the exports
table here in an attempt to improve the DevTools debugging experience,
but that needs a separate fix specifically for the inspector (which
should also take into account the imports to harvest names).
[1]: https://webassembly.github.io/spec/web-api/index.html#conventions
Fixed: chromium:1164305
Change-Id: I4bde5c8398a5164f1d8ac9060ad3743ed494c41e
Bug: chromium:1159307, chromium:1164241, chromium:1071432
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874464
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74382}
Previously we'd attach source positions to implicit returns that are
generated when leaving an async function with a promise rejection. This
was due to the use of `kNoSourcePosition` on the `end_position` in the
`ReturnStatement` nodes as indicator to pick the return position from
the function literal, instead of really not putting a source position on
that specific `Return` bytecode.
This CL adds a dedicated marker to `ReturnStatement` to express that the
`BytecodeGenerator` should put the return position from the function
literal there instead of overloading the meaning of `kNoSourcePosition`.
Bug: chromium:901819, chromium:782461
Fixed: chromium:1199919, chromium:1201706
Change-Id: I3647e0c3d711e9c3d6ae44606b70ec92ad82e1cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859945
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74301}
cpplint rules change over time, and we change the exact rules we enable
for v8. This CL removes NOLINT annotations which are not needed
according to the currently enabled rules.
R=ahaas@chromium.org
Bug: v8:11717
Change-Id: Ica92f4ddc9c351c1c63147cbcf050086ca26cc07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859854
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74297}
The "Restart frame" feature was implemented as part of LiveEdit and
primarily used to support LiveEdit of active functions, but that was
previously disabled as part of https://crrev.com/c/2846892 because it's
too brittle and causes crashes when using seemingly unrelated features.
The "Restart frame" feature was also available as a context menu item
separately in the DevTools front-end, but that was also already removed
as part of https://crrev.com/c/2854681 earlier. So all uses are gone
now.
This change works by marking Debugger.restartFrame as deprecated and
having it respond with a ServerError all the time. It thus allows us to
remove a whole bunch of machinery that was essentially just put in
various places to support the restart_fp_ magic. In particular the
debugger no longer needs any machine specific builtins now.
Bug: chromium:1195927
Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484
Fixed: chromium:1203606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74276}
Previously we'd allow to replace the source of functions that are on the
current execution stack under certain conditions, but this has resulted
in an endless stream of bugs due to weird edge cases, and so we're now
limiting LiveEdit to functions that don't have any activation (including
not a suspended generator / async function activation).
We might eventually add the ability to LiveEdit functions with
activations and have them "upgrade upon next invocation", but that
doesn't seem to be an extremely important use case right now.
Fixed: chromium:1195927
Change-Id: I87a45ba4d0ddcfbf867bd4e73738d76b2d789e04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846892
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74249}
* Failed tests that also trigger GCs are not filtered out. They are
expected to be fixed when TPH supports real garbage collection.
Bug: v8:11641
Change-Id: I30b8bcf48d5e3f32439eeffb39d28ee45db2a21c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2849822
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Cr-Commit-Position: refs/heads/master@{#74212}
Prior to this patch, `new RegExp('a/b')` logs the following in
the DevTools Console:
/a/b/
This is syntactically invalid.
This patch fixes this while simplifying regular expression printing
in general by leveraging `RegExp#toString`, instead of duplicating
the logic on the inspector side. This is possible thanks to the recent
work on making `RegExp#toString` more robust (v8:1982).
Bug: chromium:1202013, v8:1982
Change-Id: I14ccc1892f4a99361ad170fea608ace630740991
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848463
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74169}
Prior to this patch, the RemoteObject for e.g. `/x/d` got a
`description` that omitted the new `d` (`hasIndices`) flag.
Bug: v8:11684, v8:9548
Change-Id: I774fbd9620c6f3f2f19b819c9009fab7cc2e3229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848460
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74148}
Enabling and disable RCS at runtime races with concurrent threads
that use RCS.
Bug: v8:11338
Change-Id: I8fa9edcbaefc339f88b2a0d079d094a7e4290fbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2840446
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74074}
The test fails because of the race condition between concurrent GC
threads and the destructor of the test.
Bug: v8:11413
Change-Id: I5a138a61c16ddf2398e7c54defe6cc4008ca3330
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839552
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74065}
This change slipped into https://crrev.com/c/2820970 and wasn't
intended. We actually need to rule out __proto__ here explicitly,
otherwise it starts showing up in previews for embedder objects
(i.e. for HTMLAllCollection, etc.).
Bug: chromium:1197019
Change-Id: Iadde73747c157c2b5b013b11a6b8a30cc4394a7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831481
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74009}
With a shared cage, there's no easy way to recover an Isolate from a
heap pointer. Symbol::Description relies on RO symbols' description slot
being uncompressed so a Handle could point to it. This isn't possible
with a shared cage without going through TLS to get an Isolate for
Handle construction, so deprecate the method in favor of one that takes
an Isolate directly.
Bug: v8:11460
Change-Id: I69b2b7d77f4c00d0f58954cd80e22cba5ff222e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2802860
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73924}
This is a reland of 2b94e5677f
Original change's description:
> [inspector] Report [[Prototype]] as internal property.
>
> Previously the inspector was trying to add a special `__proto__`
> property to every JSObject, which looked and behaved like a real
> data property on the object. But this is confusing to developers
> since `__proto__` is not a real data property, but usually an
> accessor property on the `Object.prototype`.
>
> Additionally all other internal properties are reported using the
> [[Name]] notation, with the [[Prototype]] having been the strange
> outlier.
>
> Drive-by-cleanup: Use an ArrayList to collect the name/value pairs
> inside Runtime::GetInternalProperties(), which makes this function
> more readable and easier to add things.
>
> Bug: chromuium:1162229
> Fixed: chromium:1197019
> Screenshot: https://imgur.com/a/b7TZ32s.png
> Change-Id: Ic4c1e35e2e65f90619fcc12bf3a72806cadb0794
> Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814565
> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73881}
Bug: chromuium:1162229, chromium:1197019
Screenshot: https://imgur.com/a/b7TZ32s.png
Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM
Change-Id: Ie1e2276b385b18a5f865fdae583d1ce0101157c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2820970
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73899}
This reverts commit 2b94e5677f.
Reason for revert: Speculative based on layout test failures on
win and mac which could block the roll:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Win/5294https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Mac/4955
Original change's description:
> [inspector] Report [[Prototype]] as internal property.
>
> Previously the inspector was trying to add a special `__proto__`
> property to every JSObject, which looked and behaved like a real
> data property on the object. But this is confusing to developers
> since `__proto__` is not a real data property, but usually an
> accessor property on the `Object.prototype`.
>
> Additionally all other internal properties are reported using the
> [[Name]] notation, with the [[Prototype]] having been the strange
> outlier.
>
> Drive-by-cleanup: Use an ArrayList to collect the name/value pairs
> inside Runtime::GetInternalProperties(), which makes this function
> more readable and easier to add things.
>
> Bug: chromuium:1162229
> Fixed: chromium:1197019
> Screenshot: https://imgur.com/a/b7TZ32s.png
> Change-Id: Ic4c1e35e2e65f90619fcc12bf3a72806cadb0794
> Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814565
> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73881}
Bug: chromuium:1162229
Change-Id: Ia893ad672eb370fa6fce7eddf2947bf8f6755831
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2818386
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73886}
Previously the inspector was trying to add a special `__proto__`
property to every JSObject, which looked and behaved like a real
data property on the object. But this is confusing to developers
since `__proto__` is not a real data property, but usually an
accessor property on the `Object.prototype`.
Additionally all other internal properties are reported using the
[[Name]] notation, with the [[Prototype]] having been the strange
outlier.
Drive-by-cleanup: Use an ArrayList to collect the name/value pairs
inside Runtime::GetInternalProperties(), which makes this function
more readable and easier to add things.
Bug: chromuium:1162229
Fixed: chromium:1197019
Screenshot: https://imgur.com/a/b7TZ32s.png
Change-Id: Ic4c1e35e2e65f90619fcc12bf3a72806cadb0794
Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814565
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73881}
These tests unnecessarily rely on the `//# sourceURL` annotation. This
is preparatory work to eventually move the treatment of `sourceURL` to
the DevTools front-end.
Bug: chromium:1183990
Change-Id: I934eb1580f503b7b9f8d97c250b7c798bc67e268
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814568
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73878}
The inspector has some magic to add a special __proto__ property to
object value mirrors as long as the object itself has a [[Prototype]].
However it doesn't check whether the object already has a regular
property named __proto__ and thus confuses the front-end by sending two
properties with the same name.
Fixed: chromium:1193250
Change-Id: I75a1cd78ba94aeda4afedcc0f1e69b8dadb6673f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2810784
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73836}
That test is already slow on non-tsan bots, and we do not need TSan
coverage here. Thus keep it skipped, but update the comment.
R=mslekova@chromium.org
Fixed: v8:11610
No-Try: true
Change-Id: I1dedcc7b4d5736aca7c4cc0dc0526e4df7502440
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2797290
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73766}
In inspector-task.cc, the frontend and backend runners are explicitly
joined before going out-of-scope. On POSIX platforms, calling
pthread_join() on a thread that has already been joined has undefined
behavior. For example, under the musl C runtime library, a successful
call to pthread_join() will unmap the pthread_t thread information
region, and calling pthread_join() again will result in SIGSEGV.
R=clemensb@chromium.org, szuend@chromium.org
Change-Id: Ifdf34ed190df4c722c135ef043a3df588973b984
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2785905
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73699}
This happens flakily on ClusterFuzz. It might not be relevant for users,
but fixing it will allow ClusterFuzz to make more progress.
R=szuend@chromium.org
Bug: chromium:1190898
Change-Id: I7d0b705ff66e80e17ffc322b5d5fd5eb252d5965
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778174
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73596}
This fixes a bug in which CompileTopLevel has a pending exception
that is never taken care of. This CL adds a check for the output
of CompileTopLevel and clears the pending exceptions if existent.
Also-by: bmeurer@chromium.org
Bug: chromium:1190290
Change-Id: Ieba537d5af78fc35475f9547c240c70850bea608
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773346
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73561}
This is a more canonical type name, and is in line with {kVoidCode}.
Change-Id: Iaae9524b6fb6ecaafd63ce81cf30e3d01ca3e525
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2775565
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73557}
The original CL was reverted because PC authentication was missing for
the `caller_pc` in the stack walk. This caused a crash on the CFI bot.
PS1 is the original CL, later patch sets contain the fix.
Original Message:
[wasm] Emit safepoint info for callee-saved registers in the deopt-index
Encode safepoint info of callee-saved registers in the deopt index of
the normal safepoint.
R=clemensb@chromium.org, jkummerow@chromium.org
Change-Id: I633cd715eccc697e888cd381e3bda1a47d0d0851
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759520
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73464}
Add a test for a module without a start function; in that case, we want
to break when first calling into the module (via an exported function).
R=bmeurer@chromium.org
Bug: chromium:1151211
Change-Id: Id14978b5feff4dcd64cff828951f2a00b73c9736
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2763880
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73440}
This reverts commit 74960db4db.
Reason for revert: Segfaults on CFI: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/4999/overview
Original change's description:
> [wasm] Emit safepoint info for callee-saved registers in the deopt-index
>
> Encode safepoint info of callee-saved registers in the deopt index of
> the normal safepoint.
>
> Change-Id: I93bd0d2330b7f592b767860743c04a65ddaa92f5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739977
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73395}
Change-Id: Ic4803b06a64b615f2258c594b601b4e8fd4b7bff
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759513
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73396}
Encode safepoint info of callee-saved registers in the deopt index of
the normal safepoint.
Change-Id: I93bd0d2330b7f592b767860743c04a65ddaa92f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739977
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73395}
This changes the behavior of SetBreakpointForScript to find more
accurate break positions.
Previously, setting a breakpoint would only consider the shared
function info that contained the requested position for setting a
breakpoint. More intuitively, a breakpoint should not necessarily
be set in a function that contains the position, but in the closest
breakable location that comes after the position we requested.
To achieve this we:
1. find the shared function info of the inner most function
that contains the requested_position.
This function's end position is used to find other shared function
infos in step 2.
2. search for all shared function infos that intersect with the
range [requested_position, inner_most_function.break_position[.
3. From the shared function infos extracted in 2, find the one
that has the closest breakable location to requested_position.
Also-By: bmeurer@chromium.org
Fixed: chromium:1137141
Change-Id: I4f4c6c3aac1ebea50cbcad9543b539ab1ded2b05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742198
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73392}
Previously `setBreakpointByUrl` and friends would only filter based on
line number to find matching scripts. But that didn't work when there
were multiple scripts in the same line (i.e. minified HTML), and we'd
end up setting multiple breakpoints in different inline scripts, looking
for the next possible break location in each of them individually.
Fixed: chromium:1183664
Also-By: pfaffe@chromium.org, kimanh@chromium.org
Change-Id: I957811d30aa71609a38da75f33a24c0f720116f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2749155
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73332}
This is the V8 side change for https://crrev.com/c/2744048, which an
explicit "stack" property into the (renamed) "Expression" scope to align
the behavior and appearance of that scope with the other scopes.
Fixed: chromium:1159310
Bug: chromium:1071432, chromium:1159307
Change-Id: Ic070c50b674d8c1cff4a93538f708cc431c3f2cb
Screenshot: https://imgur.com/a/ryFiOGA.png
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748591
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73321}
In contrast to wasm modules, asm.js modules have an empty source URL.
Thus loosen a DCHECK and handle the nullptr source_url correctly.
Also add regression tests that check that we don't crash. Those can
later be extended to check that the profile looks as expected; for now
they only check that we terminate.
R=bmeurer@chromium.org
Bug: chromium:1185919
Change-Id: I6b879f540a2c3647920ad2970efcf7c94712d8c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2745895
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73313}
This fixes a null pointer access in FindSharedFunctionInfo that
was introduced when adding a guard to top level function
compilation.
Bug: chromium:1185540
Change-Id: I24b9752637aba0e660bd8f20be83522e1009b69f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742194
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73258}
This adds support for WasmGC objects (structs/arrays) to the
inspector backend. For prettier printing, it also adds support
for reading the "type" and "field" subsections of the "name"
section in Wasm modules.
This patch includes a revert of most of commit
crrev.com/987a7f4ae45ebfc986525075277debdf73001fc2 because
types are more complicated now.
Bug: v8:7748, chromium:1177784
Change-Id: Icec52cbbb32291b0e773b40be6771a678c6ec79b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715193
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73212}
Remove most dependencies on v8_wrappers. The remainder all depend on
v8_libbase anyway, so just fold it into that target which removes a gn
check error. Also removes v8_wrappers from the fuzzers where it's not
used.
Bug: v8:7330
Change-Id: I916806b62f8c49cc1d50ef493aa900e30fc623aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716383
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73041}
This adds a re-compilation of top level functions in
getPossibleBreakpoints if no candidates could be found.
This step is necessary as the GC may remove SharedFunctionInfo about
top-level functions.
Bug: chromium:1137141
Change-Id: I8830438d78751ba318d65f43d790ee98f306a57e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696154
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73008}
This CL introduces a test runner flag to detect if webassembly has been
disabled. Since all tests that require wasm are alrady skipped in
lite mode, we introduce a has_webassembly flag for the test runner which
checks for v8_enable_webassembly=true and v8_enable_lite_mode=false.
As a drive-by, we also do not set the V8_ENABLE_WEBASSEMBLY
preprocessor flag if lite mode is enabled.
The status files are updated by splitting wasm tests from the
"lite_mode" section and checking for "not has_webassembly" instead.
Note that the v8_enable_webassembly=false configuration is not tested
on any bot currently, but I will make sure that all tests keep passing
on further changes in this configuration.
R=machenbach@chromium.org
Bug: v8:11238
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Change-Id: I1841eb1f1633cb47e0c079f4a4a4d769ca3a9cbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710425
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72898}
Eager evaluation in DevTools console relies on the builtins side
effect attribution.
Setters on Date object should be marked as no side effects if called
on the temporary object.
This bug was uncovered after considering screenshot from a tweet [1].
[1] https://twitter.com/shuding_/status/1362132984376160256
Change-Id: Iedc0e29e2bdab719304e2f0a0435845f24eaaadc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2703459
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72835}
In case there's no exact match for the breakable location in
SetBreakpoint(), don't try to find the syntactically closest break
location, but rather find the first possible break location in bytecode
order. In particular when trying to set a breakpoint in a line with
for-of or an array destruction, there's no point in going for the
syntactically closest to the beginning of the line, but rather go for
the semantically first, as the intiution for setting a breakpoint on a
line is that the debugger stops before it executes anything on said
line. In the example
```
var [^a, ^b] = ^func();
```
there are three possible break locations, and the correct one is the
last one as the call to func will happen first at runtime.
For generators that's currently broken because of the implicit initial
yield, and same with modules (see crbug.com/901819), so we keep the
previous behavior of finding the closest breakable location, and will
fix that independently in a follow up CL.
Bug: chromium:901819
Fixed: chromium:782461
Also-By: yangguo@chromium.org
Change-Id: Ie724c5cb08e5f4edd90a450d99e001dff06bbe7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696586
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72813}
This adds a call to re-compile top level functions in case
no shared function info could be found. We ran into a bug
where it was not possible to set a breakpoint on the
top-level function since it was already removed by the GC.
Bug: chromium:1137141
Change-Id: I5bb6984825eee8ebcb44619e15b3acf3d118b9bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672181
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72738}
Also block sending "type" as part of the ObjectPreview, but only send
the "value" property. The front-end will be updated to display
WasmValueObject's similar to what we do for wrapper objects (i.e.
StringWrapper and the like). The matching front-end change is still
pending.
Also refactor the WasmValueObject to have dedicated constructors for
the individual types (i32, i64, f32, f64, externref and v128). This
way we can just reuse the existing logic in descriptionForObject()
and we also don't need to store the "type" on the object itself (not
really performance sensitive, but fewer moving parts / things that
can go wrong).
This also addresses the crash in https://crbug.com/1166077#c16 since
the WasmValueObject instances now have a proper JSFunction in their
maps' constructor_or_backpointer slot and are thus able to locate
their creation context. Note that this doesn't generally address
https://crbug.com/1166077 itself, but only the WasmValueObject case.
Screenshot: https://imgur.com/kbd3bix.png
Bug: chromium:1170282, chromium:1071432
Bug: chromium:1159402, chromium:1166077
Change-Id: Iae649cad155efd774cfb1f4eea8cf406e413c03a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692574
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72736}
This CL adds support for instrumentation breakpoints in wasm. The
request for "break on entry" is set on the script, and we need to keep
it stored there because there might not be any instances of that wasm
module yet. Once instances get created, the flag value is transferred to
all instances. The flag stored there is then checked in the function
prologue in Liftoff debugging code. This ensures that we will stop at
the first valid break position in any function within that module.
Hitting that instrumentation breakpoint will then clear the flag from
the script and from all other live instances (in the same isolate).
A first basic test is contained in this CL. More tests will be added
later.
R=thibaudm@chromium.org, bmeurer@chromium.org
Bug: chromium:1151211
Change-Id: I5442d4044934988269becececc03699b850d51d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690588
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72701}
This reverts commit b471bc9318.
Reason for revert: Seems like we don't reliably deliver scriptParsed events on reload after this CL.
Original change's description:
> [wasm] Send a single scriptParsed event per script
>
> If a script was shared between multiple modules (because they used the
> same wire bytes) it could happen that we still triggered multiple
> "scriptParsed" events via CDP. This was because
> {WasmEngine::GetOrCreateScript} did not communicate back whether it
> used a cached script or whether it created a new one.
>
> This CL moves the call to {Debug::OnAfterCompile} (which triggers the
> "scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
> such that we only call it once per script.
> Since the engine only holds a weak reference to the script, we would
> still trigger multiple events if the script is garbage-collected in the
> meantime. In this case there is no way around this, as the new script
> would have a new ID, hence we need to emit a new event to make it
> public to the debugger.
>
> R=thibaudm@chromium.org
> CC=bmeurer@chromium.org
>
> Bug: chromium:1151211
> Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72648}
TBR=clemensb@chromium.org,bmeurer@chromium.org,thibaudm@chromium.org
Change-Id: I6cc299734e4fcff29289355973e7660b60b49a25
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1151211
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689199
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72667}
If a script was shared between multiple modules (because they used the
same wire bytes) it could happen that we still triggered multiple
"scriptParsed" events via CDP. This was because
{WasmEngine::GetOrCreateScript} did not communicate back whether it
used a cached script or whether it created a new one.
This CL moves the call to {Debug::OnAfterCompile} (which triggers the
"scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
such that we only call it once per script.
Since the engine only holds a weak reference to the script, we would
still trigger multiple events if the script is garbage-collected in the
meantime. In this case there is no way around this, as the new script
would have a new ID, hence we need to emit a new event to make it
public to the debugger.
R=thibaudm@chromium.orgCC=bmeurer@chromium.org
Bug: chromium:1151211
Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72648}
This very large changeset adds support for RISC-V.
Bug: v8:10991
Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344
Commit-Queue: Brice Dobry <brice.dobry@futurewei.com>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72598}
BREAKING CHANGE: The values of Wasm locals, stack, and globals are now
represented as objects instead of holding the (primitive) values
directly, and SIMD128 values are no longer represented as Uint8Arrays.
The DWARF extension has been prepared for this breaking change.
The new `WasmValue` comes with `type` and `value` properties that hold
its contents. The motivation here is that this is a more extensible
approach. In case of SIMD128, the `value` property holds the canonical
string representation, which has the additional advantage that these
values can be compared with `===` (and `==`).
This partially reverts https://crrev.com/c/2614428, the main difference
here being that WasmValue is now a proper JSObject that can be exposed
on the DebugEvaluate proxy API.
Screenshot: https://imgur.com/rcahNKM.png
Bug: chromium:1170282, chromium:1071432, chromium:1159402
Change-Id: Iea304e3680775123c41deb4c3d172ac949da1b98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643384
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72570}
This is a reland of 6ada6a90ee
- Fixed a GC issue
https://bugs.chromium.org/p/v8/issues/detail?id=11335:
GC expected all arguments on the stack from code with
CodeKind::TURBOFAN to be tagged objects. This is not the case now with
inlined Wasm calls, and this information can be passed in
SafepointEntry for each call site.
- Disabled JS-to-Wasm inlining for calls inside try/catch.
For more details, see updated doc:
https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
Bug: v8:11092
Original change's description:
> Reland "Faster JS-to-Wasm calls"
>
> This is a reland of 860fcb1bd2
>
> - Disabled the tests for this feature in V8-lite mode (the original
> change broke V8-lite tests).
> - Also modified test console-profile-wasm.js that was brittle with this
> change because it assumed that there was always a JS-to-Wasm wrapper
> but this is not the case when the TurboFan compilation completes before
> the Liftoff-compiled code starts to run.
>
> More changes in Patchset 8:
>
> - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
> into a new phase, wasm-inlining that reuses the JSInliner reducer.
> The doc
> https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
> describes the new logic.
>
> - Fixed a couple of small issues in wasm_compiler.cc to make sure that
> the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
> this should solve the problem we had inlining the calls in functions
> that can throw exception.
Original change's description:
> Faster JS-to-Wasm calls
>
> This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
>
> Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> the basis of the signature of a Wasm function to call, and whose task
> is to:
> - set "thread_in_wasm_flag" to true
> - convert the arguments from tagged types into Wasm native types
> - calculate the address of the Wasm function to call and call it
> - convert back the result from Wasm native types into tagged types
> - reset "thread_in_wasm_flag" to false.
>
> This CL tries to improve the performance of JS-to-Wasm calls by
> inlining the code of the JS-to-Wasm wrappers in the call site.
>
> It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> this kind of calls. A 'JSWasmCall' node is associated to
> WasmCallParameters, which contain information about the signature of
> the Wasm function to call.
>
> WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid
> generating code to convert the types for the arguments
> of the Wasm function, when the conversion is not necessary.
> The actual inlining of the graph generated for this wrapper happens in
> the simplified-lowering phase.
>
> A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> lazy deoptimizations that can happen if the Wasm function callee calls
> back some JS code that invalidates the compiled JS caller function.
>
Bug: v8:11092
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72541}
Previously the WebAssembly debugger support completely ignored the
condition on breakpoints. With this change, we check conditions
(snippets of JavaScript) properly, which enables not only conditional
breakpoints in the front-end, but also other features like 'Never pause
here' (which simply sets `false` as condition) and log points.
Fixed: chromium:1173007
Bug: chromium:1173006
Change-Id: I02c740d383378a1f4cc08134ad571bea08e9a905
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2666690
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72485}
Conditional breakpoints are not implemented yet; the condition is just
ignored for wasm. This CL adds a test for conditional breakpoints. The
output is expected to change once the implementation is finished.
R=bmeurer@chromium.org
Bug: chromium:1173007
Change-Id: I15e0053ec8b57e28b8eadc208f35bbf70437682e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2666692
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72478}
Even though we sped up the test since the first landing of the CL, it
still sometimes times out on TSan. Since TSan coverage is not needed for
this test, just skip it.
R=adamk@chromium.org
Bug: v8:11369
Change-Id: I7825d1824ad34fccc313459a115b38eae1d5b553
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659262
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72437}
This adds a regression test for https://crrev.com/c/2652488. The test
reduces the available code space such that it would trigger an OOM
condition if code is not garbage-collected.
In order to guarantee garbage-collection in all configurations, an
explicit interrupt check is added to the WasmDebugBreak runtime
function.
R=thibaudm@chromium.org
Bug: chromium:1168564
Change-Id: I8fce7aa5128c9e3c9a7e2d2e7397c394fec7de85
Cq-Include-Trybots: luci.v8.try:v8_linux64_asan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_asan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652490
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72435}
This adds a [[WebAssemblyMemory]] internal property to ArrayBuffer and
SharedArrayBuffer instances that are owned by WebAssembly.Memory
objects. This allows the devtools-frontend to find the
WebAssembly.Memory for any given ArrayBuffer, making it possible to
properly support WebAssembly.memory.grow() eventually, but also showing
a reasonable tab title.
Before: https://imgur.com/hod9jPR.png
After: https://imgur.com/v195VoC.png
Bug: chromium:1171621, chromium:1171619, chromium:1166577
Change-Id: Ife22cabdfcf54ab30c234ea4ca86bfbb711ab2f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653155
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72403}
This reverts commit 0938188f85.
Reason for revert: new test times out on tsan: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/35152/overview
Original change's description:
> [wasm][debug] Garbage-collect stepping code
>
> All wasm code has an initial ref count of 1, in the expectation that it
> will be added to the code table. When the code is removed from that
> table, the ref count will be decremented.
> Stepping code (and also other code under special circumstances) will not
> be added to the code table though. Hence the ref count will never be
> decremented below 1, and the code will never be garbage-collected.
>
> This CL fixes this, by decrementing the ref count if the code is not
> added to the code table.
> Note that the code will only be collected if no isolate is currently
> using it, so it won't be collected while still in use for stepping.
>
> R=thibaudm@chromium.org
>
> Bug: chromium:1168564
> Change-Id: I3047753591cbc52689ca019e9548ec58c237b835
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649040
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72354}
TBR=clemensb@chromium.org,thibaudm@chromium.org
Change-Id: I84f84324d2c4a3cae2ae6b97f469e3f22b0e3b3f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1168564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652485
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72357}
All wasm code has an initial ref count of 1, in the expectation that it
will be added to the code table. When the code is removed from that
table, the ref count will be decremented.
Stepping code (and also other code under special circumstances) will not
be added to the code table though. Hence the ref count will never be
decremented below 1, and the code will never be garbage-collected.
This CL fixes this, by decrementing the ref count if the code is not
added to the code table.
Note that the code will only be collected if no isolate is currently
using it, so it won't be collected while still in use for stepping.
R=thibaudm@chromium.org
Bug: chromium:1168564
Change-Id: I3047753591cbc52689ca019e9548ec58c237b835
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649040
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72354}
This reverts commit 6ada6a90ee.
Reason for revert: Revert for link issue:
https://bugs.chromium.org/p/v8/issues/detail?id=11335
Original change's description:
> Reland "Faster JS-to-Wasm calls"
>
> This is a reland of 860fcb1bd2
>
> - Disabled the tests for this feature in V8-lite mode (the original
> change broke V8-lite tests)
> - Also modified test console-profile-wasm.js that was brittle with this
> change because it assumed that there was always a JS-to-Wasm wrapper
> but this is not the case when the TurboFan compilation completes before
> the Liftoff-compiled code starts to run.
>
> More changes in Patchset 8:
>
> - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
> into a new phase, wasm-inlining that reuses the JSInliner reducer.
> The doc
> https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
> describes the new logic.
>
> - Fixed a couple of small issues in wasm_compiler.cc to make sure that
> the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
> this should solve the problem we had inlining the calls in functions
> that can throw exception.
>
>
> Original change's description:
> > Faster JS-to-Wasm calls
> >
> > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
> >
> > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> > the basis of the signature of a Wasm function to call, and whose task
> > is to:
> > - set "thread_in_wasm_flag" to true
> > - convert the arguments from tagged types into Wasm native types
> > - calculate the address of the Wasm function to call and call it
> > - convert back the result from Wasm native types into tagged types
> > - reset "thread_in_wasm_flag" to false.
> >
> > This CL tries to improve the performance of JS-to-Wasm calls by
> > inlining the code of the JS-to-Wasm wrappers in the call site.
> >
> > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> > this kind of calls. A 'JSWasmCall' node is associated to
> > WasmCallParameters, which contain information about the signature of
> > the Wasm function to call.
> >
> > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
> > of the Wasm function, when the conversion is not necessary.
> > The actual inlining of the graph generated for this wrapper happens in
> > the simplified-lowering phase.
> >
> > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> > lazy deoptimizations that can happen if the Wasm function callee calls
> > back some JS code that invalidates the compiled JS caller function.
> >
> > Bug: v8:11092
> > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> > Cr-Commit-Position: refs/heads/master@{#71824}
>
> Bug: v8:11092
> Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
> Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72147}
Tbr: ahaas@chromium.org, jgruber@chromium.org
Bug: v8:11092, v8:11335
Change-Id: Iab2908928dfe7ea353f70cb5d3bf2de4d3074db6
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644758
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72253}
The V8 inspector is using the DebugPropertyIterator (a debug only
interface) while building RemoteObjects. The DebugPropertyIterator
uses the `KeyAccumulator::GetKeys` for this, which can potentially
throw, but the DebugPropertyIterator ignores exceptions and keeps
iterating. If multiple iteration steps throw an exception
(e.g. due to a pending stack overflow), we run into a CHECK in
Isolate::Throw, as we can't throw exceptions while another
exception is still pending.
This CL fixes the CHECK crash by properly propagating exceptions
after the iterator is created or advanced and returning early
in the inspector if an exception happens.
Please note that the regression test that showcases this behavior
is still disabled, as fixing the crash causes currently an
endless loop. While the exception in `ValueMirror::getProperties`
is handled by early returing, we still need to forward it as
the result of the `Runtime::evaluate` all the way up the stack.
R=bmeurer@chromium.org, yangguo@chromium.org
Bug: chromium:1080638
Change-Id: I1d55e0d70490a06a6bc1b0a3525236411da7f64b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639954
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72203}
This is a reland of 860fcb1bd2
- Disabled the tests for this feature in V8-lite mode (the original
change broke V8-lite tests)
- Also modified test console-profile-wasm.js that was brittle with this
change because it assumed that there was always a JS-to-Wasm wrapper
but this is not the case when the TurboFan compilation completes before
the Liftoff-compiled code starts to run.
More changes in Patchset 8:
- Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
into a new phase, wasm-inlining that reuses the JSInliner reducer.
The doc
https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
describes the new logic.
- Fixed a couple of small issues in wasm_compiler.cc to make sure that
the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
this should solve the problem we had inlining the calls in functions
that can throw exception.
Original change's description:
> Faster JS-to-Wasm calls
>
> This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
>
> Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> the basis of the signature of a Wasm function to call, and whose task
> is to:
> - set "thread_in_wasm_flag" to true
> - convert the arguments from tagged types into Wasm native types
> - calculate the address of the Wasm function to call and call it
> - convert back the result from Wasm native types into tagged types
> - reset "thread_in_wasm_flag" to false.
>
> This CL tries to improve the performance of JS-to-Wasm calls by
> inlining the code of the JS-to-Wasm wrappers in the call site.
>
> It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> this kind of calls. A 'JSWasmCall' node is associated to
> WasmCallParameters, which contain information about the signature of
> the Wasm function to call.
>
> WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
> of the Wasm function, when the conversion is not necessary.
> The actual inlining of the graph generated for this wrapper happens in
> the simplified-lowering phase.
>
> A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> lazy deoptimizations that can happen if the Wasm function callee calls
> back some JS code that invalidates the compiled JS caller function.
>
> Bug: v8:11092
> Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#71824}
Bug: v8:11092
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72147}
Remove the ambient dependency on the currently entered isolate, let the
embedder pass it in explicitly.
Bug: v8:11287
Change-Id: I03690390a308a59e2c6ea5c6ae268780d836b717
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2608209
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72105}
This skips sending the data urls along with Runtime.CallFrame,
and Runtime.ExceptionDetails.
Also-by: bmeurer@chromium.org
Bug: chromium:1132260
Change-Id: I45136bc0d3217caf8fbd93946b021f56f64f04b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621077
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72063}
This moves the logic for the debug name heuristic, which derives names
for imported and exported entities from the relevant tables, into
wasm-debug.{cc,h} and stores these maps on the DebugInfoImpl rather than
on the WasmModule.
Drive-by-fix: Also use the import table based heuristic for function
names, just like we use it for everything else.
Bug: chromium:1164305
Change-Id: I8a21e0880c680079f63e6607b5b62c788049b9e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625870
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72061}
This adds the following internal properties to `WasmInstanceObject`
values in DevTools:
- `[[Module]]` pointing to the `WasmModuleObject`, allowing the
developer to find the module to an instance no matter where in
DevTools front-end the instance is inspected.
- `[[Functions]]`, `[[Globals]]`, `[[Memories]]`, and `[[Tables]]`
are shown (when they aren't empty), allowing developers to inspect
the entities within an instance no matter where in DevTools front-end
it's inspected.
This also updates the _Module_ scope for Wasm frames to show the entity
containers (`functions`, `globals`, `memories` and `tables`) in addition
to the `instance` and `module` to make it easier accessible (fewer
clicks to get there), but also to align it better with the _Add property
path to Watch_ and _Copy property path_ features (since exactly the same
names are exposed via Debug Evaluate on Wasm frames).
```
> Stack
> Locals
v Module
> module
> instance
> functions
> globals
> memories
> tables
```
Drive-by-fix: Move GetWasmModuleObjectInternalProperties() logic into
debug-wasm-support.cc
Screenshot: https://imgur.com/ksEHG2I.png
Doc: http://bit.ly/devtools-wasm-entities
Fixed: chromium:1165294
Bug: chromium:1071432, chromium:1164241, chromium:1165304
Change-Id: Ia88fb2705287c79988ff2b432e4a33ac34e098f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622912
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72042}
The watchdog previously didn't terminate execution, it just prevented
the execution of additional tasks.
This CL fixes that by making {TaskRunner::Terminate} actually terminate
execution in the isolate.
It also adds a regression test for this.
R=szuend@chromium.org
Bug: chromium:1154412, chromium:1142437
Change-Id: Ic6638e8a5c37e8840a85651b4d4bea2ee0f71c43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622212
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72031}
This change unifies the locals, stack, and globals objects exposed for
WebAssembly frames via the Scope view and via DebugEvaluate to use the
same underlying objects (implemented via interceptors). This also
means that for locals and globals we now consistently expose names
prefixed by a dollar symbol everywhere.
Drive-by-fix: Move the debug::ScopeIterator implementation for WasmFrame
into debug-wasm-support.cc, so WebAssembly scope details are all found
in one place instead of scattered around the code.
Drive-by-cleanup: Rename GetJSDebugProxy to GetWasmDebugProxy for
consistency. GetJSDebugProxy is a bit misleading, since the debug proxy
is not about JavaScript, but just exposed to JavaScript.
Doc: http://bit.ly/devtools-wasm-entities
Bug: chromium:1159307, chromium:1127914, chromium:1162229
Change-Id: If932bd06bbce72542823f63dac1bd976ab33937a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615348
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72009}
New internal properties expose the byte length of an ArrayBuffer as well
as the pointer to the backing store, which will serve as a unique ID
to show when SharedArrayBuffers in different workers are the same buffer.
Bug: chromium:1163800
Change-Id: I49930765cb38f75ba5c6cee5a0a6827f4fec42d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618242
Commit-Queue: Eric Leese <leese@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72000}
Previously the Debug Proxy API that's exposed on Wasm frames by
Runtime.evaluateOnCallFrame() was implemented via actual JSProxy
instances. That means that all entities such as "memories", "tables",
"stack", "globals", etc. were JSProxy instances with "get" and "has"
traps. But that has a couple of down-sides:
1. In DevTools front-end, the proxies are shown as JSProxy, which is not
very useful to developers, since they cannot interact with them nor
can they inspect their contents. And the object preview also only
shows "Proxy {}" for them.
2. The performance doesn't scale well, which becomes a painful
bottleneck with larger Wasm modules that contain hundreds of
thousands of functions or globals.
3. We cannot use the JSProxy instances in the Scope view (for the
reasons outlined in 1.) and hence we have different logic to provide
Scope values than values in the rest of DevTools, which led to subtle
but annoying bugs and inconsistencies.
This also changes the "locals" implementation by querying the values
ahead of time, similar to the object exposed to the Scope view, instead
of on-demand, since the "locals" object might survive the current
debugger pause and peeking into the stack afterwards would read invalid
memory (and might even be a security issue). For being able to change
locals we need to look into a similar solution as what we have for
JavaScript locals already. The expression stack already works this way.
For performance reasons (especially scaling to huge, realistic Wasm
modules), we cache the per-instance proxies ("functions", "memories",
"tables" and "globals") on the WasmInstanceObject and reuse them (which
is safe since they have a `null` prototype and are non-extensible), and
we also cache the proxy maps (with the interceptors) on the
JSGlobalObject per native context.
Doc: http://bit.ly/devtools-wasm-entities
Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241
Change-Id: I6191035fdfd887835ae533fcdaabb5bbc8e661ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606058
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71981}
Previously we had introduced a special `v8::internal::WasmValue` type
which we used to expose Wasm values to the Scope view in Chromium
DevTools. The problem however is that these values cannot be exposed to
JavaScript (and in particular not to Debug Evaluate), which means that
particularly for v128 and i64 we have inconsistent representations
across the various parts of DevTools.
This change removes the `wasm` type from the RemoteObject and all the
adjacent logic, and paves the way for a uniform representation of Wasm
values throughout DevTools. For i64 we will simply use BigInt
consistently everywhere, and for i32, f32 and f64 we'll just use Number.
For externref we will represent the values as-is directly. For v128
values we currently use a Uint8Array, but will introduce a dedicated
WasmSimd128 class in a follow-up CL.
Bug: chromium:1071432
Fixed: chromium:1159402
Change-Id: I0671e5736c9c27d7ca376e23ed74f16d36e03c80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614428
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71962}
The wasm-scope-info-liftoff.js and wasm-set-breakpoint-liftoff.js tests
were originally testing the Liftoff path (when we still had the Wasm
interpreter), and have received some updates along the way. Nowadays the
interpreter is going and the non-liftoff versions of these tests don't
provide any additional test coverage, but are merely a slightly less
updated version of the liftoff test.
Bug: chromium:1162229
Change-Id: Ifc9933d47f33674a83b99425ef9d0e4bc5550323
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2609415
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71909}
Consistently use InspectorTest.runAsyncTestSuite() in wasm inspector
tests to make tests easier to debug (they'll fail instead of timing
out in case of errors).
Bug: chromium:1162229, chromium:1071432
Change-Id: I7aada196f9e34071aa1bb059bb45f85f75226060
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2609414
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71908}
The "imports" and "exports" that were exposed on WebAssembly frames via
Debug-Evaluate aren't useful for the DWARF C/C++ extension (and likely
not for any other language extension), since they only expose static
information that's easily available (upfront) by reading the Wasm wire
bytes.
In fact, there are already standardized functions in the WebAssembly
specification, namely `WebAssembly.Module.imports(module)` and
`WebAssembly.Module.exports(module)`, which yield static information
about the imports and exports of a Wasm module.
So instead of exposing special, non-standard "imports" and "exports", we
now instead expose both the "instance" and the "module" objects via both
the Debug Proxy and the Scope view, and also add internal [[Exports]]
and [[Imports]] properties to WasmModuleObject, which under the hood use
the standard methods mentioned above.
Fixed: chromium:1162069
Bug: chromium:1071432, chromium:1083146
Screenshot: https://imgur.com/lcaW2jL.png
Doc: https://docs.google.com/document/d/1rqbu0jKTl3q_xCxLnKzkjGXWEsHnJ9aERVhKV9RNDgE#bookmark=id.925bb2qgou38
Change-Id: Ie27e55bb08ea5f90493c57375bf2b48dfb11a4d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606050
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71893}
For JSArrayBuffer instances (which map to both v8::ArrayBuffer and
v8::SharedArrayBuffer), we add a couple of synthetic views to its
ValueMirror to make it easy for developers to peak into the contents of
the JSArrayBuffer. These were previously real properties, but that's
just wrong (both intuitively and semantically), and they should instead
be internal properties.
Drive-by-fix: The [[IsDetached]] internal property should only be shown
on actually detached JSArrayBuffer's to reduce visual clutter. And for
detached JSArrayBuffers creating views on them throws TypeErrors per
specification, so we shouldn't attempt to display views on them.
Bug: v8:9308, chromium:1162229
Change-Id: Ia006de7873ca4b27aae7d00d46e1b69d2e326449
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606047
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71892}
