For globals, we would use name as follows.
1. If import: use <import_module>.<field_name> from WasmImport.
2. If export: use <field_name> from WasmExport.
3. Use global<index>.
Add DecodeGlobalNames similar to DecodeFunctionNames.
Doc: https://docs.google.com/document/d/1XoXWONLBgZWQ9dhtoMpQPvD0fnnWA50OorsuSXfME3g
Bug: v8:10242
Change-Id: I11131528fc6ae6ca50727e9b428f76e76b0000e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122523
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66910}
The last test will not be fixed in the context of enabling debugging in
Liftoff. Instead, it will fail until we implement anyref in Liftoff.
Thus, assign the new tracking bug to it.
R=thibaudm@chromium.org
Bug: v8:10351, v8:10356
Change-Id: Ic184f390841b0994bf37bbf5f7ecc13e6cf1f957
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124322
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66905}
When stepping in from JS, the stepping frame ID will not be set.
Instead of ensuring to set it properly, we can just skip the check for
the frame ID. It was needed before, when we didn't properly reset
stepping information. Now, it's redundant anyway.
Also, ensure that we don't redirect to the interpreter if the
--debug-in-liftoff flag is set.
Drive-by: Fix and clang-format some parts of the test (no semantic
change).
R=thibaudm@chromium.org, szuend@chromium.org
Bug: v8:10351
Change-Id: I58a3cd68937006c2d6b755a4465e793abcf8a20c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124317
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66904}
The output extends by four more breaks, since when stepping out of the
function that has the breakpoint, we now also step through the two
other functions on the stack.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: I4b042cad0d88b923c3894fe979c43837260eb958
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124315
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66892}
There are only three tests with differing behaviour if Liftoff is used
for debugging.
This CL thus stages the --debug-in-liftoff flag behind --future (tested
by the "future" variant) and excludes the three tests.
This allows us to test the other (already working) tests for
regressions, and iteratively shrinking down the list of failing tests.
Drive-by: Tier down modules in tests before testing debugging features
to avoid hitting a DCHECK in Liftoff recompilation for debugging.
R=thibaudm@chromium.org, ecmziegler@chromium.org
Bug: v8:10351
Change-Id: I3b1dd1a29258ecf13c1f60020fb06358005558d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122021
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66889}
This patch changes the order in which stack values are shown
in the stack scope. As a result, changes to the stack show up
at the end of the stack.
Bug: chromium:1043034
Change-Id: I735fc29d3957b6484589554ce046114e1b7bd9e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122987
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66884}
This is a minor cosmetic fix. Wasm opcodes are bytes, hence they should
always be printed as an even number of hexadecimal digits.
Note that currently we only print a single byte anyway, but in the
future we will want to extend this to correctly parse multi-byte
opcodes. Those will also be printed as an even number of characters
then.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: I2423277b470d74c1c72cb619c2a43bb978423bc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122025
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66883}
Most control structures in WebAssembly do not have a clear execution
semantics, they are more like markers. Hence the execute state, and the
change in the state, when breaking on them and stepping over them is
unclear.
Hence this CL just makes them non-breakable. If the user tries to set a
breakpoint on them, this breakpoint will automatically be propagated to
the first instruction after the respective control opcode (this is
tested for other cases in existing tests).
R=thibaudm@chromium.org
Bug: v8:10326
Change-Id: Iaf540a94789c9cbc87d23ddfb794e4b01776b49f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122017
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66876}
We were sometimes stopping on a one-shot breakpoints in JS code even
though the last user action was actually a resume.
This CL fixes that clearing all stepping in JS whenever we hit a
breakpoint in wasm.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: Ie5d12bb0c9e766bcbd5ad0aa225a8b14b4d608b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120588
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66869}
This change adds a stack scope for wasm debugging.
Currently the local scope contains both local variables as well as
the expression stack. For now, this change duplicates the information
available on stacks into the stack scope, until we have added
support for the stack scope in the DevTools front-end.
Bug: chromium:1043034
Change-Id: Ib0a07e07be7c53003526a7b1e1dbfaa1116b41ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093510
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66867}
Using the "logSourceLocation" function from protocol-test.js prints
slightly better location information for wasm, and especially much
better information for JS breakpoints. This helps understanding and
debugging these tests.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: I51c7d168d2cb19fb8469b4a2eb372c2b95650fcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120539
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66863}
This enables the --debug-in-liftoff flag in the wasm-scope-info test.
The expected output slightly differs, because we get another breakpoint
at the end of the function body, which was actually missing before.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: Ic2628b26591763cea17403f74fe0f6d935633e6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120535
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66859}
A StringView is pretty light, so this should be similar to
how absl::string_view is typically used, e.g. see the guidance here:
https://github.com/abseil/abseil-cpp/blob/master/absl/strings/string_view.h
I suspect this reasoning holds even though StringView (defined
just above StringBuffer in v8-inspector.h) carries an additional bool.
This yields a small simplification of the StringBuffer implementations.
Change-Id: I03f850049afe2327913070838f39649fcdfa6fa8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045110
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66858}
A StepOver at a return (either explicit return instruction, or implicit
return at the end of the function) should stop again in the caller
frame.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: I313e6b612ac52e73b33ef07c6da1ced2aa0db600
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110250
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66852}
This fixes issues with replacing the return address of deeper (non-top)
wasm frames, i.e. frames which are at a call position. The replaced
address should also point after the call in the new code, so we don't
execute the same call again.
This is achieved by using slightly different encodings for breakpoint
positions and other (wasm instruction) positions. Breakpoints set
{is_instruction} to {false} in the source position table entry, whereas
usual wasm instruction set it to {true}.
Also, during stack walking for OSR, we remember whether we want to OSR
to the position before the instruction (if it's the top frame), or after
the call instruction (if it's deeper in the stack). We then use the
{is_instruction} predicate to find the right location.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: I73212a7532c6ecf4c82bde76fe4059c8203e422c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116206
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66850}
Since now the IterationBody StackChecks are implicit within JumpLoops,
we are able to eagerly deopt in them. If we do that, whenever we advance
to the next bytecode we don't have to advance to the next literal
bytecode, but instead "advance" in the sense of doing the JumpLoop.
Adding tests that test this advancing for wide and extra wide JumpLoops.
Also, marking JumpLoop as needing source positions since now it has
the ability of causing an interrupt.
Bug: v8:10149, v8:9960
Fixes: v8:10149
Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66809}
Update the "hook on function call" flag also in the wasm case, and
slightly change the {IsStepping} logic to stop in any frame if the last
step action was anything other than StepNext.
In future CLs, this has to be extended further for StepOut and for
StepOver at a return location.
When that is done, we can also reenable more stepping in the test.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: Ib3aa8c2c2e137690140e5879a33e2bcc340821e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108035
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66789}
And fix a few issues revealed by this new test. Incidentally, the test
uses removeBreakpoint which was still untested with Liftoff. But as
expected this seems to work out of the box.
R=clemensb@chromium.org
Bug: v8:10321
Change-Id: Ifa4e867737d925ea8c6c9731575a32f3da3e16dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106206
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66752}
Add a scriptLanguage enum to the new scripts events. This overhauls
crrev.com/c/2011083 that was related. Report the code section offset
as well as the script language on the Debugger.scriptParsed and
Debugger.scriptFailedToParse events.
Bug: chromium:1057569
Change-Id: I40b43f28f0b3e094720db4fc1f07db1a0c293ee0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083025
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66749}
At the moment when the static private method is unused
in source code (either explicitly or through eval) but is accessed
at runtime through the debugger, and there are no other potential
references to the class variable in the source code otherwise,
the reference to the class variable is lost here since the class
variable would not be context-allocated, then we could not rebuild
a proper brand check for it.
For now, a ReferenceError would be thrown and the method is considered
"optimized away", similar to how unused ordinary methods in closures
work. Before this patch it would DCHECK when generating bytecode
for the debugger instead of throwing errors.
Bug: v8:9839, v8:8330
Change-Id: I5d63131a7bdba141d01a3e6459bc27d0f5953c1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095637
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66734}
Port 83ff405b1a
Original Commit Message:
Flood functions with breakpoints to prepare them for stepping. With a
small modification to the runtime function, this already implements a
basic step over functionality.
We still cannot resume, step in or step out (including stepping over a
return instruction).
R=thibaudm@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Id153b2611c528e679e8d7722e3d209fb15bcf6d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105055
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66724}
This tests inspecting a bigger number of registers (covers all registers
on many platforms). It also executes all four intrinsic types (i32, i64,
f32, f64).
R=thibaudm@chromium.org
Bug: v8:10222
Change-Id: I340696d525e4001f241bb22f62f0338018ad9804
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102575
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66720}
This implements inspection of live registers on breakpoints in Liftoff.
To that end, the frame pointer of the WasmDebugBreak frame is remembered
when iterating the stack. Based on a platform-specific implementation of
{WasmDebugBreakFrameConstants}, the offset of the respective register
within that frame is computed, and the value is read from the frame.
As a drive-by, the wasm debug side table is storing register codes as
liftoff codes, which can also store register pairs (needed for i64 on
32-bit platforms, and for SIMD, which is not supported yet).
R=jkummerow@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10222
Change-Id: I01b669baf56430e100cd46cc46f210121ea679da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102574
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66719}
Flood functions with breakpoints to prepare them for stepping. With a
small modification to the runtime function, this already implements a
basic step over functionality.
We still cannot resume, step in or step out (including stepping over a
return instruction).
R=clemensb@chromium.org
Bug: v8:10321
Change-Id: Ia4a6335d24c1a511c2f1fc9b48d728f327b3df56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098732
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66697}
When looking for private members in an object for the inspector,
we check if that object is a class constructor with the a bit
has_static_private_methods set on its SFI. If it
is, we look for any variables in the context locals
with a VariableMode associated with private methods or accessors
and a IsStaticFlag being kStatic.
This patch also filters out static private methods when inspecting
instances.
Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
See also: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit
Bug: v8:9839, v8:8330
Change-Id: Idad15349c983898de2ce632c38b0174da10e639d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955664
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#66636}
We now always tier down to Liftoff when the debugger is enabled, hence
we don't need to force Liftoff-only execution in the test.
R=thibaudm@chromium.orgCC=duongn@microsoft.com
Bug: v8:9654
Change-Id: I9b9e21b2ee977b349bb4f5d0e34c6ebf82166cb9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093504
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66630}
String::NewFromLiteral is a templated function that takes a char[N]
argument that can be used as an alternative to String::NewFromUtf8 and
returns a Local<String> rather than a MaybeLocal<String> reducing the
number of ToLocalChecked() or other checks.
Since the string length is known at compile time, it can statically
assert that the length is less than String::kMaxLength, which means that
it can never fail at runtime.
This also converts all found uses of NewFromUtf8 taking a string literal
or a variable initialized from a string literal to use the new API. In
some cases the types of stored string literals are changed from const
char* to const char[] to ensure the size is retained.
This API does introduce a small difference compared to NewFromUtf8. For
a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
would treat this as a 3 character string, whereas the new API will treat
it as a 7 character string.
As a drive-by fix, this also fixes all redundant uses of
v8::NewStringType::kNormal when passed to any of the String::New*
functions.
Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66622}
When an empty class is nested inside a class with private instance
methods, like this:
class Outer {
constructor() {}
#method() {}
factory() {
class Inner {
constructor() { }
}
return Inner;
}
run(obj) {
obj.#method();
}
}
The bytecode generator previously generate private brand
initialization for the constructor of Inner by mistake,
because during scope chain serialization/deserialization,
the outer scopes of Inner and factory() are not allocated
or serialized (as they are empty). In the eyes of the bytecode
generator, it then appeared as if Outer is the direct outer
scope of Inner's constructor.
In order to work around this information loss, in this patch
we rely on SharedFunctionInfo instead of the Context/ScopeInfo
chain to maintain the information about private brand initialization.
This is done by shrinking expected_nof_properties to 8 bits and
freeing 8 bits for a second bitfield on the SFI.
Design doc: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit#
Bug: v8:9839, v8:8330, v8:10098
Change-Id: I4370a0459bfc0da388052ad5a91aac59582d811d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056889
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66575}
Example can be inspector tests.
Bug: v8:10264
Change-Id: I996bb68d0f36920568a04f93cd8c1256a4f41a96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070912
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66572}
We want to be consistent with wasdk/wasmparser.
The names used in V8 should follow the WAT convention and always start
with a dollar, both for names from the "names" section as well as
generated names.
Bug: v8:10242
Change-Id: If4dbd4c38208c9dd9377dd2f79120635a531d881
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070637
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66434}
This extends the existing test to also print scope information on every
break. Note that the currently printed information is not correct, since
register values are not reconstructed yet. We just always print {-11}
for register values.
Thus the expected output will change with follow-up CL.
R=thibaudm@chromium.org
Bug: v8:10222
Change-Id: I7be13ecb02957454c875a4280cec154a08c2deb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062403
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66433}
This is a reland of 78defee492
Original change's description:
> [inspector] Check that wasm wrappers appear in profiles
>
> This extends the existing wasm profiling test to also check that
> wasm-to-js and js-to-wasm wrappers appear in the profiles as expected.
> It thus serves as a regression test for the status quo.
>
> R=bmeurer@chromium.org
>
> Bug: chromium:1054386
> Change-Id: I5d4d8e6a252c6eb266b910621fca43a6ff0837bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066970
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66401}
TBR=bmeurer@chromium.org
Bug: chromium:1054386, v8:10266
Change-Id: Iae04c0564ee8f0330d61ce954d895a41497c5a85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071260
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66424}
This reverts commit 827107a7dc.
Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1054664
Original change's description:
> [wasm-debug] Let wasm scripts report correct column information.
>
> In the debugger, wasm scripts currently do not contain meaningful column
> informations. Fix that by keeping track of the offset and size of the
> wasm code section inthe module and reporting that to the debugger.
>
> Bug: chromium:1042636
> Change-Id: Ie2b5d3a50952a467d256f815c16e459cb0ae600e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011083
> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65913}
Bug: chromium:1042636
Change-Id: Ic59d71111c3274688828bdbf6894f7f3274dc50a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066983
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66409}
This reverts commit 78defee492.
Reason for revert: Timeout on TSan: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/30410
Original change's description:
> [inspector] Check that wasm wrappers appear in profiles
>
> This extends the existing wasm profiling test to also check that
> wasm-to-js and js-to-wasm wrappers appear in the profiles as expected.
> It thus serves as a regression test for the status quo.
>
> R=bmeurer@chromium.org
>
> Bug: chromium:1054386
> Change-Id: I5d4d8e6a252c6eb266b910621fca43a6ff0837bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066970
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66401}
TBR=clemensb@chromium.org,bmeurer@chromium.org
Change-Id: Iac4299d5a4dc74041fbceac98cd2c2b96b9425df
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1054386
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069328
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66406}
This extends the existing wasm profiling test to also check that
wasm-to-js and js-to-wasm wrappers appear in the profiles as expected.
It thus serves as a regression test for the status quo.
R=bmeurer@chromium.org
Bug: chromium:1054386
Change-Id: I5d4d8e6a252c6eb266b910621fca43a6ff0837bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066970
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66401}
After compiling a function with a different set of breakpoints, update
return addresses on the stack so that execution resumes in the new
code.
This allows new breakpoints to take effect immediately, which is the
expected behavior and a prerequisite for stepping.
R=clemensb@chromium.org
Bug: v8:10147
Change-Id: I67eb3b4ce23a1f3b0519935447f8b847ec888ead
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064218
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66351}
Since liftoff is turned on upon debugger.enable, these tests need to be
skipped.
Change-Id: Icaa02ffb77d0bbcb24b2c232e519c0547e714a24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062940
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66335}
Store a flag per isolate whether new modules should be kept in
tiered-down state from the beginning. Adjust initial compilation if flag
is set.
Bug: v8:9654
Change-Id: I5aae435fb807f3eaa7efafe9af60451ad3c7e14d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028452
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66321}
REPL 'let' declared variables use VariableLocation::REPL_GLOBAL which
was not handled by a switch in the bytecode generator. The default
case ran into an UNREACHABLE.
This CL fixes this by properly handling VariableLocation::REPL_GLOBAL
for delete.
Drive-by: Replaced the default case with an explicit case for
VariableLocation::MODULE.
Bug: chromium:1052721
Change-Id: I1330ff2f2c6f042a596a8298599a5d58769894f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060488
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66301}
By replacing usage of the IsNotArrayIndex bit with IsNotIntegerIndex,
we get back one bit that we can use to increase the number of hash bits
stored. The price is that strings that represent array/integer indices
beyond the cacheable range will have to be scanned more often, but these
strings should be rare, and we expect that the additional hash bit is
more worthwhile to have.
Bug: v8:9904
Change-Id: I33f74b0a73f4754aee85805d4b7c409177668439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051947
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66299}
If new Liftoff code is generated but we already have either Liftoff or
TurboFan code, we still want to install and use the new Liftoff code if
we are in debugging.
This logic can probably be simplified again when the "tier down to
liftoff on Debugger.enable" logic is fully implemented. I left a TODO to
revisit the logic later.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: Ie3a6bdf1cde4f1af884edc8cf1f1b5a507283a5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036089
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66129}
This CL fixes a parser crash in REPL mode. Some SyntaxErrors can cause
the AST to contain NULL nodes, resulting in a crash when we want to
rewrite the AST after parsing.
Instead of re-writing a broken AST we bail early.
R=leszeks@chromium.org
Bug: chromium:1040034, chromium:1045758
Change-Id: I9c559f6de5969c8db17833ccbdb1608627b46311
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023547
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66008}
Add a test that does the same thing the devtools-frontend does when
evaluating console inputs.
1) Declare a const variable with throwOnSideEffect=true. This should
throw.
2) Declare the same const variable with throwOnSideEffect=false.
This should successfully declare the variable.
Previously it could be the case that even though we threw in 1), the
variable would fail to be initialized in 2) with a re-declaration
error.
Bug: chromium:1043151
Change-Id: I1a6126b518f7bb3788c39b9f8e3adb8850aa962a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016587
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65991}
Port 7b79a02d2b
Original Commit Message:
This CL adds a --debug-in-liftoff flag, which takes another path in
{WasmScript::SetBreakPointForFunction}, and sets the breakpoint via
{wasm::DebugInfo} (Liftoff-related) instead of {WasmDebugInfo} (C++
interpreter related).
Actual breakpoint support is not there yet, so the new test which sets
this flag does not currently break anywhere. This will change with a
future CL.
R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I632e4c945c88f58d8caba8688356f66406bc04aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016915
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#65953}
This CL adds a --debug-in-liftoff flag, which takes another path in
{WasmScript::SetBreakPointForFunction}, and sets the breakpoint via
{wasm::DebugInfo} (Liftoff-related) instead of {WasmDebugInfo} (C++
interpreter related).
Actual breakpoint support is not there yet, so the new test which sets
this flag does not currently break anywhere. This will change with a
future CL.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: I95a905e666b8f502366d2c7273c8f25a267ee184
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2012920
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65921}
Changing script context handling from bytecode based to metadata on the
function. This fixes the debugger to explicitly check the code rather
than implicitly relying on a NewScriptContext bytecode causing side
effects.
Bug: chromium:1043151
Tbr: ulan@chromium.org
Change-Id: I38c5c04d7c76155e0a055ae6efd57f25986bdb7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013117
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65920}
Add a test that const declarations are recognized as having side-
effects in REPL mode.
Bug: chromium:1043151
Change-Id: I6f8038ab4a5ee446d23904ed46637223157db5c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013114
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65916}
In the debugger, wasm scripts currently do not contain meaningful column
informations. Fix that by keeping track of the offset and size of the
wasm code section inthe module and reporting that to the debugger.
Bug: chromium:1042636
Change-Id: Ie2b5d3a50952a467d256f815c16e459cb0ae600e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011083
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65913}
This fixes the DevTools console preview when using REPL mode.
AsyncFunction* intriniscs are side-effect free and marking them as such
is correct.
Bug: chromium:1043151
Change-Id: Ie0c36507b98b0c12f3d627c34102c04c27358ff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010106
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65876}
Previously these would silently fail unless the caller checked the
.error property of the return value. There are no tests that check
iteractions with non-existent methods so this should always be an
error at the test runner level, rather than relying on clients to
check the error.
1. Fix the tests that accidentally call methods that don't exist.
2. Change the test runner so that it prints an error and ends the test.
3. Add a test that the test runner does #2.
Bug: v8:10134
Change-Id: Idd619950a057290c565d58fba6db3ddbcaf2c5eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2006093
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65835}
Re-use set breakpoint logic for wasm script to set breakpoint to first
breakable position of given wasm function.
Bug: v8:9724
Change-Id: Ibd6b59d5b93c6895f71f0114291bf78db03aee0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2001564
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65827}
This makes Liftoff inspection (scope reporting) also use the decoded
names of locals, which are now stored in a C++ data structure (see
https://crrev.com/c/2002541).
The call to {SetOwnPropertyIgnoreAttributes} had to be replaced by a
proper lookup first, to handle integer names and duplicate names
correctly. The test already covered these cases.
The test was extended by another unnamed local to also test the
generation of default names in case no name is provided.
R=thibaudm@chromium.org
Bug: v8:10019
Change-Id: I475bb4db9a32c39203180e9c8d3f8181c3882138
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002544
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65821}
This way we don't need to generate bytecodes to push the context.
This drops the stack trace for redeclaration SyntaxErrors but keeps the
message location. This is in line with what we do for other
SyntaxErrors.
Change-Id: Id8e3cc348b4d56a8196753baf51cfd810f07512b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997439
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65810}
This extends the debug side table to track stack offsets of locals and
operand stack slots, and uses this to read spilled value from the
physical stack frame when inspecting Liftoff frames.
R=jkummerow@chromium.org
Bug: v8:10019
Change-Id: Ida7ab5256fcc1e9d408201f4eafe26919f1432a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000739
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65789}
This fixes local names that are the string representation of a valid
element index.
Even though both the Liftoff and the interpreter-based test are changed,
only the latter needs to be fixed right now since Liftoff does not use
the names currently. Modifying the test just ensures that we implement
this correctly once we use the name.
R=jkummerow@chromium.org
Bug: v8:10019
Change-Id: Ib7f7d6e244a344a85ab540b6c2c67f98b1f3078e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1998079
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65751}
Due to the changes introduced int this CL:
https://chromium-review.googlesource.com/c/v8/v8/+/1991498
wasm-scope-info-liftoff needs to be skipped until
lifoff is enabled. Details can be found in the comment
section of the above link.
Change-Id: I1f61d1685a6ec2e81dab84b003f984a706d45737
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993906
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#65726}
This brings the test back in sync with the wasm-scope-info-liftoff test
after the comments on https://crrev.com/c/1975754.
R=jkummerow@chromium.org
Bug: v8:10021
Change-Id: I8e3751fdb11fb32a0112c0706559a6d26e2e7594
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977860
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65723}
This CL adds timestamps to coverage updates. This is useful for clients,
because between requesting a coverage update and collecting coverage data
significant time may pass. This change allows precise attribution at what
time a coverage update was taken.
Change-Id: I65a9cccb0171e892b7dbe35d105d3ca246ba08d0
Bug: chromium:1022031
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992435
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65696}
This provides local scope information for Liftoff frames. Note that two
things remain to be fixed:
1) We still need to refactor decoding of locals names such that it's
available also for Liftoff frames.
2) We need to load spilled values from the stack frame.
This will be added in a follow-up CL.
R=jkummerow@chromium.org
Bug: v8:10019
Change-Id: I2af1287d2989ab7b88c4293aac099bca95282063
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991498
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65686}
Inspector will no longer report per-function wasm scripts or
provide wasm disassembly. Locations in wasm are now consistently
reported through the inspector API as lineNumber=0
columnNumber=byte offset in module.
Bug: chromium:1013527, chromium:1003022
Change-Id: Ide85bbaa85ad75f29248ff82a3e7f3e40688d377
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991481
Commit-Queue: Eric Leese <leese@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65660}
This adds a {wasm::DebugInfo} struct which will hold the
{wasm::DebugSideTable}s for individual Liftoff functions, and will use
them to construct local scope information.
R=jkummerow@chromium.org, bmeurer@chromium.org
Bug: v8:10019
Change-Id: I7869cec5000e9b126c891a242fcccfc53c67662e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1975758
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65563}
This adds a respective test, even though Liftoff frames currently do not
show scope information. The output will change with future CLs.
R=jkummerow@chromium.org
Bug: v8:10019
Change-Id: I015863768c02678e97404f2edb538e3b4320d134
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1975754
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65540}
In setting breakpoint in wasm, we can find wasm script from location but
in removing a breakpoint, only breakpoint id is provided. For wasm, we
have a list of all BreakPointInfo objects attached to the Script. From
breakpoint id, we iterates all scripts to find the targeted breakpoint
and remove it.
Bug: chromium:837572
Change-Id: Ia5d0fb7d804fb98270b2103232bc10eb5d4f93a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1959749
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65505}
When V8 throws an uncaught exception, we store a JSMessageObject
with a stack trace and source positions on the isolate itself.
The JSMessageObject can be retrieved by a TryCatch scope
and is used by the inspector to provide additional information to the DevTools
frontend (besides the exception).
Introducing top-level await for REPL mode causes all thrown exceptions
to be turned into a rejected promise. The implicit catch block that does this
conversion clears the JSMessageObject from the isolate as to not leak memory.
This CL preserves the JSMessageObject when the debugger is active and stores
the JSMessageObject on the rejected promise itself. The inspector is changed
to retrieve the JSMessageObject in the existing catch handler and pass the
information along to the frontend.
Drive-by: This CL removes a inspector test that made assumptions when a promise
is cleaned up by the GC. These assumptions no longer hold since we hold on to
the promise longer.
Bug: chromium:1021921
Change-Id: Id0380e2cf3bd79aca05191bc4f3c616f6ced8db7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967375
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65497}
Allocate memory more quickly so the test completes faster. (On the ARM
simulator tests with slow asserts and verify-heap, it was taking around
20 minutes).
Change-Id: I6b4d0a4788817c4f996a073cc3fdf8b69d11bc40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973731
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65495}
This patch implements inspector support for private instance methods:
- Previously to implement brand checking for instances with private
instance methods we store the brand both as the value with the brand
itself as the key in the stances. Now we make the value the context
associated with the class instead.
- To retrieve the private instance methods and accessors from the
instances at runtime, we look into the contexts stored with the
brands, and analyze the scope info to get the names as well as
context slot indices of them.
- This patch extends the `PrivatePropertyDescriptor` in the inspector
protocol to include optional `get` and `set` fields, and make the
`value` field optional (similar to `PropertyDescriptor`s).
Private fields or private instance methods are returned in the
`value` field while private accessors are returned in the `get`
and/or `set` field. Property previews for the instaces containing
private instance methods and accessors are also updated similarly,
although no additional protocol change is necessary since the
`PropertyPreview` type can already be used to display accessors.
Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
Bug: v8:9839, v8:8330
Change-Id: If37090bd23833a18f75deb1249ca5c4405ca2bf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934407
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65337}
Reverting https://chromium-review.googlesource.com/c/v8/v8/+/1741660
This fixed one bug but caused a lot of others and on balance I think
reverting it is the lesser evil.
This also fixed generator-relocation.js because
(function*(){}).constructor is the function constructor and we try to
set a breakpoint on line 3.
Bug: chromium:109362, chromium:1028689
Fixes: v8:9721
Change-Id: I1bfe6ec57ce77ea7292df91266311f5c0194947e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1940259
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65232}
This scenario is where user is at the end of Wasm execution and do
some stepping. Hence, user should be back at Javascript frame. We
can detect that stepping as it exits Wasm Interpreter and prepare
debugging as a step-out-ish in Javascript.
Bug: chromium:823923, chromium:1019606, chromium:1025151
Change-Id: I29022af0d5e5dcf78d87e83193f6e16fec954e87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1912985
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65122}
A previous CL (https://crrev.com/c/1926769) changed hashing to always
treat the input as signed values. This causes problems, since the hash
of a one-byte string differs the hash of the identical two-byte string.
Hence this CL switches to treating all values as unsigned in hashing.
The bug cannot easily be reproduced in v8 alone, since we would need to
create an internalized two-byte string, which contains one-byte data.
Blink manages to create such a string via external strings.
R=jkummerow@chromium.org
Bug: chromium:1025184, chromium:1027131
Change-Id: Id41aa0e463691c02099a08c6e9d837a079c872df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930615
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65113}
This is an unmodified reland of 3c98a2a36a.
The actual issue was fixed in https://crrev.com/c/1926769.
Original change's description:
> [wasm] Prevent breakpoints on nonbreakable positions
>
> If a breakpoint is set on a non-breakable position, the wasm interpreter
> just stores the value 0xFF (kInternalBreakpoint) in the function body
> (actually, a copy of the function body). This might overwrite immediates
> and cause subsequent failures in the wasm interpreter.
>
> In JavaScript, breakpoints are just forwarded to the next breakable
> position. This CL implements the same for WebAssembly.
> A cctest tests this behavior, and the existing
> wasm-stepping-byte-offsets.js inspector test is extended to also set the
> breakpoint within an i32 constant immediate.
>
> R=leese@chromium.org, mstarzinger@chromium.org
> CC=bmeurer@chromium.org
>
> Bug: chromium:1025184
> Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65070}
Bug: chromium:1025184
Change-Id: I5e16df645bbacf039b7a5e55a0c2a64cdb4c6a32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926152
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65093}
This reverts commit 3c98a2a36a.
Reason for revert: Fails on arm: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/12134
Original change's description:
> [wasm] Prevent breakpoints on nonbreakable positions
>
> If a breakpoint is set on a non-breakable position, the wasm interpreter
> just stores the value 0xFF (kInternalBreakpoint) in the function body
> (actually, a copy of the function body). This might overwrite immediates
> and cause subsequent failures in the wasm interpreter.
>
> In JavaScript, breakpoints are just forwarded to the next breakable
> position. This CL implements the same for WebAssembly.
> A cctest tests this behavior, and the existing
> wasm-stepping-byte-offsets.js inspector test is extended to also set the
> breakpoint within an i32 constant immediate.
>
> R=leese@chromium.org, mstarzinger@chromium.org
> CC=bmeurer@chromium.org
>
> Bug: chromium:1025184
> Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65070}
TBR=mstarzinger@chromium.org,clemensb@chromium.org,bmeurer@chromium.org,leese@chromium.org
Change-Id: I7468ea3b15fecccdea521308325cf4851e0a0396
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1025184
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926032
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65074}
If a breakpoint is set on a non-breakable position, the wasm interpreter
just stores the value 0xFF (kInternalBreakpoint) in the function body
(actually, a copy of the function body). This might overwrite immediates
and cause subsequent failures in the wasm interpreter.
In JavaScript, breakpoints are just forwarded to the next breakable
position. This CL implements the same for WebAssembly.
A cctest tests this behavior, and the existing
wasm-stepping-byte-offsets.js inspector test is extended to also set the
breakpoint within an i32 constant immediate.
R=leese@chromium.org, mstarzinger@chromium.org
CC=bmeurer@chromium.org
Bug: chromium:1025184
Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65070}
We detect a stepping in Wasm from Javascript into Wasm then prepare
the target function for debugging.
The trick is redirect the target to interpreter and set a 'fake'
breakpoint in the first instruction. Currently we don't need to clear
this 'fake' breakpoint since it won't notify unless user intend to
step in.
Change-Id: Ibe1f9ba31dc6c7919895d3fe31967e9c4699ef63
Bug: chromium:1019606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1902259
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65020}
Currently the inspector reports Wasm in one of two ways:
- If there is a source map, report one script per Wasm script, with
bytecode but no source.
- If there is no source map, report one script per Wasm function, with
source (Wasm disassembly) but no bytecode.
With this change, behavior with source map is same, but without source
map it will report both ways. This will allow us to change the frontend
to do its own disassembly, allowing us to remove the per-function scripts
in a future change.
Bug: chromium:1013527
Change-Id: I0c559ad08896e8d0da419e3c6ad8d1edff3976fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1899782
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Eric Leese <leese@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64980}
This patch excludes brand symbols from the result of
JSReceiver::GetPrivateEntries so that the brands do not show up
when the instances are inspected from the DevTools (e.g. via
`Runtime.getProperties()`).
To implement this, we use a bit in the Symbols to denote whether
it's a brand symbol. A brand symbol is also a private name
symbol so that we can just reuse the IC for accessing private
names and do not need to jump through extra ORs.
Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
Bug: v8:8671, v8:9839, v8:8330
Change-Id: I24346aeedce3602395289052d1e1350ae9390354
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1909757
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#64899}
There already exists a optional boolean flag 'replMode' for the
'Runtime.evaluate' command. This CL ferries the flag from the inspector
to DebugEvaluate::Global.
The existing DebugEvaluate::GlobalREPL is removed in favor of a
the REPLMOde enum to reduce code duplication.
Bug: chromium:1018158
Change-Id: Iafb43a3015b6876a02ac0db6cdfcac2cfa388862
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881149
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64801}
The new APIs are:
enableRuntimeCallStats
disableRuntimeCallStats
getRuntimeCallStats
The RunTime Call Stats are collected per isolate.
Change-Id: I7e520e2c866288aa9f9dc74f12572abedf0d3ac8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881601
Commit-Queue: Peter Kvitek <kvitekp@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64784}
Currently, when debugging wasm, the internal script URL is shown, which
has the form wasm://wasm/wasm-<hex-script-id>. With this change, if the
module specifies a module name, it would report the URL as
wasm://wasm/<module-name>-<hex-script-id>, as this will help the user
identify what they are debugging.
Bug: chromium:1017678
Change-Id: I26ff6249bd1e832d62402619a68b61c115c24640
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1888810
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64703}
Some tools that transform Wasm today, already support encoding the
transforms and correctly updating locations in source maps, but not yet
in DWARF (although this is being worked on).
Until they catch up, it's best to consistently prefer source maps over
DWARF when both are present, and not just rely on order of sections as
accidentally done in the previous CL that introduced DWARF info.
Ref: crrev.com/c/v8/v8/+/1834341
Bug: chromium:1016772
Change-Id: I769311e2096ae0e4ca304bef0a0453c7e0776aae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1888930
Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64647}
This is a reland of bc8ad334cd.
The CL was innocent, thus unmodified reland with TBR.
Original change's description:
> [wasm][debug] Report global scope also for compiled frames
>
> The global scope (containing global values and the memory) can be
> produced from the instance alone, hence we can also report it for
> compiled frames.
>
> R=mstarzinger@chromium.org, jgruber@chromium.org
>
> Bug: v8:9676
> Change-Id: I20fbb74a98b00b128b6ed305b92fb56ad7dc7558
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876816
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64547}
TBR=mstarzinger@chromium.org
Bug: v8:9676
Change-Id: I2486a007156b7197d523f62ca3c30e29e7650b63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879929
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64558}
This reverts commit bc8ad334cd.
Reason for revert: breaks ASAN:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20ASAN/33137
Original change's description:
> [wasm][debug] Report global scope also for compiled frames
>
> The global scope (containing global values and the memory) can be
> produced from the instance alone, hence we can also report it for
> compiled frames.
>
> R=mstarzinger@chromium.org, jgruber@chromium.org
>
> Bug: v8:9676
> Change-Id: I20fbb74a98b00b128b6ed305b92fb56ad7dc7558
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876816
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64547}
TBR=mstarzinger@chromium.org,jgruber@chromium.org,clemensb@chromium.org
Change-Id: I7a37723286315235f0c0a63728de58633a3b259e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9676
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878713
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64549}
The global scope (containing global values and the memory) can be
produced from the instance alone, hence we can also report it for
compiled frames.
R=mstarzinger@chromium.org, jgruber@chromium.org
Bug: v8:9676
Change-Id: I20fbb74a98b00b128b6ed305b92fb56ad7dc7558
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876816
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64547}
This extends the scope info test to also contain a compiled frame.
Currently, no scope info is shown for this frame. This will change in
the future, and the expected output will be extended accordingly.
R=yangguo@chromium.orgCC=mstarzinger@chromium.org
Bug: v8:9676
Change-Id: Ie57c1fec5f7cbec737d40b18d091fc2d9a00f493
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876063
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64535}
Embedded builtins are now unconditionally enabled, which removes the
need to differentiate between enabled/disabled embedded builtins.
This Cl removes the 'embedded_builtins' variant and related
*.status entries.
R=machenbach@chromium.org
Bug: v8:8519
Change-Id: I55d0dd54735b7cc437832af6fa2836fd6c14a317
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864936
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64464}
This patch refactors the declaration and allocation of the class variable, and
implements static private methods:
- The class variable is declared in the class scope with an explicit
reference through class_scope->class_variable(). Anonymous classes
whose class variable may be accessed transitively through static
private method access use the dot string as the class name. Whether
the class variable is allocated depending on whether it is used.
Other references of the class variable in the ClassLiteral AST node
and the ClassInfo structure are removed in favor of the reference
through the class scope.
- Previously the class variable was always (stack- or context-)
allocated if the class is named. Now if the class variable is only
referenced by name, it's stack allocated. If it's used transitively
by access to static private methods, or may be used through eval,
it's context allocated. Therefore we now use 1 less context slots
in the class context if it's a named class without anyone referencing
it by name in inner scopes.
- Explicit access to static private methods or potential access to
static private methods through eval results in forced context
allocation of the class variables. In those cases, we save its index
in context locals in the ScopeInfo and deserialize it later, so that
we can check that the receiver of static private methods is the class
constructor at run time. This flag is recorded as
HasSavedClassVariableIndexField in the scope info.
- Classes that need the class variable to be saved due to
access to static private methods now save a
ShouldSaveClassVariableIndexField in the preparse data so that the
bits on the variables can be updated during a reparse. In the case
of anonymous classes that need the class variables to be saved,
we also re-declare the class variable after the reparse since
the inner functions are skipped and we need to rely on the preparse
data flags to remember declaring it.
Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit
Bug: v8:8330
Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64219}
This is useful for the upcoming "huge TypedArrays" support, to be able
to quickly decide in stubs/generated code whether a string used as the
key for a property load/store can possibly be an exotic integer index.
Bug: v8:4153
Change-Id: I50ce655d2f78fb36e5615fd580f22c9290216c84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1821460
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64165}
This brings our constants back in line with the changed spec text. We
already use kExprTableGet and kExprTableSet, but for locals and globals
we still use the old wording.
This renaming is mostly mechanical.
PS1 was created using:
ag -l 'kExpr(Get|Set)Global' src test | \
xargs -L1 sed -E 's/kExpr(Get|Set)Global\b/kExprGlobal\1/g' -i
PS2 contains manual fixes.
R=mstarzinger@chromium.org
Bug: v8:9810
Change-Id: I064a6448cd95bc24d31a5931b5b4ef2464ea88b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847355
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64163}
This brings our constants back in line with the changed spec text. We
already use kExprTableGet and kExprTableSet, but for locals and globals
we still use the old wording.
This renaming is mostly mechanical.
PS1 was created using:
ag -l 'kExpr(Get|Set|Tee)Local' src test | \
xargs -L1 sed -E 's/kExpr(Get|Set|Tee)Local\b/kExprLocal\1/g' -i
PS2 contains manual fixes.
R=mstarzinger@chromium.org
Bug: v8:9810
Change-Id: I1617f1b2a100685a3bf56218e76845a9481959c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847354
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64161}
Unfortunately, codebase contains lots of places that use one of the two
formats as an internal representation for Wasm locations:
1) {line: 0, column: byte offset within entire module}
2) {line: function index, column: byte offset within function}
These places choose these formats interchangeably and convert from one
to another depending on the presence of source map URL in Wasm.
This is not very convenient and makes it hard to add support for DWARF
which should behave just like Wasm with source maps - that is, report a
raw Wasm script instead of fake scripts per each disassembled function,
and use representation (1) instead of (2) internally.
I tried to refactor these locations and avoid checking for source map
URLs in the previous CL - https://crrev.com/c/v8/v8/+/1833688. However,
it quickly got out of hand, and updating code in one place just kept
revealing yet another that gets broken by the changes, so I made a
decision to abandon it and leave to someone who knows the codebase
better.
Instead, this CL is based on https://crrev.com/c/v8/v8/+/1809375, but,
rather than trying to integrate DWARF separately and only for supported
agents, it pretends that encountering DWARF section is the same as
encountering a `sourceMappingURL` section with fake URL "wasm://dwarf".
This ensures that Wasm with DWARF behaves exactly in the same way as
Wasm with source maps, just like we want, with minimal changes to the
codebase. The only downside is that frontends without DWARF support
won't get even a disassembled version of Wasm that contains DWARF info.
This is unfortunate, but, as per previous discussions, should be fine
given current state of Wasm debugging.
Change-Id: Ia7256075e4bfd2f407d001d02b96883d7267436e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1834341
Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64157}
If script is not disassembled, still use the same script URL format for
consistency.
In particular, use an absolute `wasm://wasm/` prefix, like disassembled fake
scripts do, instead of just a script name which appears to be a
relative URL to devtools.
Change-Id: Ib7632f9f3587ca4961eb4f0b884482b3a1a6e1f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1833685
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
Cr-Commit-Position: refs/heads/master@{#64086}
The creator of the allocator retains ownership and is responsible
for its eventual destruction.
Change-Id: Iaf1b24bee7153b3b1a75df99974adff42c6a197f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1835545
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64084}
This new optional parameter controls whether "Runtime.evaluate" ignores
break points and previous "Debugger.pause" calls while evaluating the
expression. This will be used for live expressions, which should never
interfere with debugging.
Bug: chromium:1001216
Change-Id: Ie37f6616a4a1cae40399b79255ab92fb254d91b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826664
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64018}
This addition will allow to experiment with parsing DWARF information from
WebAssembly on the frontend side for improved debugging.
The frontend must explicitly opt-in to this experiment by setting
`supportsWasmDwarf: true` in `Debugger.enable` params.
When this option is present, and Wasm appears to contain DWARF information
(heuristic: `.debug_info` custom section is present), V8 will not try to
disassemble and report each WebAssembly function as a separate fake script, but
instead will report Wasm module as a whole.
Note that V8 already does this when Wasm is associated with a source map.
Additionally, this CL adds a dedicated `Debugger.getWasmBytecode` command that
accepts scriptId and returns raw wire bytes of the chosen WebAssembly module.
Change-Id: I7a6e80daf8d91ffaaba04fa15688f2ba9552870f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809375
Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63969}
This adds an additional V8 API to get the backing store of an array
buffer. Unlike the existing API, the backing store comes wrapped
in a std::shared_ptr, making lifetime management with the embedder
explicit. This obviates the need for the old GetContents() and
Externalize() APIs, which will be deprecated in a future CL.
Contributed by titzer@chromium.org
Bug: v8:9380
Change-Id: I8a87f5dc141dab684693fe536b636e33f6e45173
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807354
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63883}
Separate creating Wasm translations from reporting them to an agent.
This is done in order to support multiple connected sessions.
Previously connecting more than one agent would fail assertion in debug
mode and overwrite translation objects over and over
(and potentially do something worse) in release mode.
Bug: v8:9725
Change-Id: I13fde5ebf6e64e7268eb6870f9c21ac9a5bed81e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807273
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
Cr-Commit-Position: refs/heads/master@{#63867}
After https://crrev.com/c/1800575 and https://crrev.com/c/1803343,
which tried to fix this on occuring compile errors, this CL
systematically adds the <memory> include to each header that uses
{std::unique_ptr}.
R=sigurds@chromium.orgTBR=mlippautz@chromium.org,alph@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org
Bug: v8:9396
Change-Id: If7f9c3140842f9543135dddd7344c0f357999da0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803349
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63767}
Currently, debugger pauses on async call schedule and then waits for Debugger.pauseOnAsyncCall
with parentStackTraceId to actually schedule the pause.
This CL combines these two steps:
- For local async tasks, it just stores m_taskWithScheduledBreak at the time of schedule,
to be able to pause once this task is run.
- For external async tasks, it plumbs "should_pause" boolean in V8StackTraceId from
the point of schedule to the point of execution, and schedules a pause once
externalAsyncTaskStarted is called with "should_pause" set to true.
This approach greatly simplifies the implementation, and reduced frontend to a single
"breakOnAsyncCall: true" parameter in Debugger.stepInto.
Drive-by: introduce hasScheduledBreakOnNextFunctionCall() to make
SetBreakOnNextFunctionCall management more robust.
Note: artificial pauses at async call schedule time are gone from test expectations -
we now only pause when user actually wants to pause, which makes protocol much simpler.
See also design doc linked in the bug.
BUG=chromium:1000475
Change-Id: I2d16f79c599fe196b2aaeca8223c63437a2954a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783724
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63737}
This increases readability of the wasm-stepping test significantly.
Drive-by: Use more 'let' instead of 'var'.
R=yangguo@chromium.org
Change-Id: If80ba3a4b92cd3ab1c994e17fb8f40f5526517da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789298
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63616}
This CL fixes a bug where function proxies were reported as functions
instead as proxies to devtools, which caused dev-tools to call methods
on the function, possibly triggering side-effects.
Change-Id: I1d5d234b784601bd4b7ec91107e4b0cf0d877d07
Bug: chromium:995753
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762303
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63307}
Since the same value is also returned in 'result' field it is still populated in accord with 'returnByValue' parameter. This behavior is consistent with 'evaluate'.
R=dgozman@chromium.org, lushnikov@chromium.org
Bug: v8:9509
Change-Id: I9f72682f87492ce5cd0759dce75ab3d75a5fe31c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1707331
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Yury Semikhatsky <yurys@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63134}
The spec says we have to insert some wrapper code with extra line breaks
in it, but this confuses users when they see stack traces as the line
numbers come from the code with the wrapper, instead of the original.
This CL sets line_offset on the script to indicate that line numbers
should be offset by the 2 extra line breaks when reading them out e.g.
for the purpose of stack traces.
Bug: chromium:109362
Change-Id: Ib608e1043c38b595b1466766f7592e993ee3b996
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741660
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63127}
Currently, the private name symbols are displayed in the block
scopes in DevTools, though these are just implementation details
of private fields. This patch hides them from the block scope
by marking variables with names starting with `#` as synthetic.
The private fields are still going to show up in the previews
of objects, only the key symbols themselves are going to be hidden.
Bug: v8:8773, chromium:982267
Change-Id: I059472d05c26a1f035ab92718a1b7e5ecafa8dc4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741846
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63112}
This CL changes {descriptionForError} to not immediately return when a {stack}
is not found, but instead try to lookup and append the {message} as well.
The existing logic to build a description in a specific way when the class
of the exception does not match, is retained for backwards compatibility.
Bug: chromium:954017
Change-Id: I9fa1d2807e2877bd988f82b4b57cf329bcd9f61b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738862
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63111}
This is a reland of a0728e869b
Original change's description:
> [d8] Remove maximum workers limitation
>
> This CL refactors the lifetime management of the v8::Worker C++ object
> and in the process lifts the 100 maximum worker limitation. To do this,
> it uses a Managed<v8::Worker> heap object and attaches the managed to
> the API worker object.
>
> R=mstarzinger@chromium.org
> BUG=v8:9524
>
> Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62932}
Bug: v8:9524
Change-Id: I7d903fb12ddb00909a9429455f46c55db2fd02de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722562
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62974}
This CL moves the code responsible for serializing a stack trace frame into
a string, out of messages.cc and into stack-frame-info.cc. Instead of
symbolizing the stack trace frame while serializing, the code is changed to
work on top of StackTraceFrame and StackFrameInfo objects.
The result is that the serialization code no longer cares when a stack trace
frame is symbolized. Symbolization could happen eagerly during capturing, or
lazily the first time any of StackFrameInfo fields are accessed.
Drive-by: Existing users of StackFrameBase::ToString are adapted to the
new SerializeStackTraceFrame API. This includes Isolate::PrintCurrentStackTrace,
which is changed to re-use the existing capturing and serializing mechanism.
Bug: v8:8742
Change-Id: Ic7fd80668c9d993e99d586ef7fe022850104c34f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631414
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62522}
This mistake was introduced during big liveedit refactoring.
Reported in Node.js: https://github.com/nodejs/node/issues/28493R=dgozman@chromium.org,yangguo@chromium.org
Change-Id: Ic19984f1776dd5e0a25c6d7c41b4a7b7a9c76d22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683101
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62479}
Just the low-hanging fruit. There is more to do.
Bug: v8:2487
Change-Id: Ia9afa32797960f6c4c7c4fa0f39c70efc63663e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669698
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62397}
Shared read-only heap means that all isolates within a process must
share the same snapshot. Pass the back-end snapshot to the front-end
runner to fix that.
Bug: v8:7464
Change-Id: I0ec591a919d4d462ef38e372907592df3c759521
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669691
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62349}
The debugger should be notified whenever a new Module is created so it
displayed properly. Without this change, the Module is only displayed once,
regardless of the number of times it is referenced (by other Workers, say).
That is potentially reasonable behavior, but it doesn't match the way
JavaScript does it.
With this change, the debugger will display the sources like this:
```
▼ top
▶ localhost
▼ wasm
▼ wasm-82570336
wasm-82570336-0
▼ worker.js
▶ localhost
▼ wasm
▶ wasm-82570336
```
Change-Id: I61177e8a07e36ea8e2234aa25e75b1489c9da95f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666616
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62297}
JSModuleNamespace does not have well defined CreationContext: current
implementation of JSReceiver::GetCreationContext crashes on CHECK.
R=lushnikov@chromium.org,yangguo@chromium.org
Bug: none
Change-Id: Ie2c0bfa39117d42d81f9709c21376c177b18e5ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652559
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62128}
Currently, in wasm-function stack traces, v8 displays the decimal offset
from the start of the function. However, the WebAssembly WebAPI
specification says that it should be a hex offset into the module.
This change makes the stack trace display with hex module offsets, as
well as fixing all the unit tests that depended on the old behaviour.
R=fgm@chromium.org, titzer@chromium.org, yangguo@chromium.org
Bug: v8:9172
Change-Id: I73737a319a42dd665521ab8a4b825199ae11c87f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1646846
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Guanzhong Chen <gzchen@google.com>
Cr-Commit-Position: refs/heads/master@{#62103}
Quotes have been added around the token to make the message clearer.
Bug: chromium:943636
Change-Id: Ic38f3e6d307157af2c0146e69fb611a2cfb46564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593307
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62074}
Bug: v8:9247
Change-Id: Id6860e7b0f932990ac3cda39e369b0809e4f6a2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632072
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61928}
These instructions were renamed in the October 2, WebAssembly CG meeting. The
issue describing the change is here:
https://github.com/WebAssembly/spec/issues/884
Change-Id: Ia9e8733156b5ed5db7fc9ab1681c1a51b874dd71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1620681
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61711}
Now that function counts are based on dedicated call counters instead
of FeedbackVector::invocation_count, we can enable optimizations for
block coverage modes.
This significantly speeds up V8 with enabled coverage:
Before this CL, the web-tooling-benchmark regressed by 70% (block
count coverage vs. no coverage). With this CL, the regression is
reduced to 40%.
Bug: v8:6000,v8:9148
Change-Id: I6bb538bd66f32f016c66c1d1996bce3b25958232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1615241
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61582}
Helper functions to create and warm-up the snapshot blob were
duplicated in various spots (mksnapshot, inspector tests, serializer
cctests). This merges all of these into a single helper function
family declared in snapshot.h.
Bug: v8:9189, chromium:957029
Change-Id: I2d8d6fd8e955ffffd7d805c199d4a858500af588
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1598695
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61576}
Prior to this CL, call counts at function scope were taken from the
FeedbackVector::invocation_count field. This had two major drawbacks:
1. for generator functions, these count the number of resumptions
instead of the number of calls; and 2. the invocation count is not
maintained in optimized code.
The solution implemented here is to add a dedicated call counter at
function scope which is incremented exactly once each time the
function is called.
A minor complication is that our coverage output format expects
function-scope counts in the dedicated CoverageFunction object, and
not as a CoverageBlock. Thus function-scope block counts are initially
marked with magic positions, and later recognized and rewritten during
processing.
This CL thus fixes reported generator function call counts and enables
optimizations in block coverage modes (more to come in a follow-up).
Drive-by: Don't report functions with empty source ranges.
Bug: v8:6000,v8:9148,v8:9212
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: Idbe5edb35a595cf12b6649314738ac00efd173b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613996
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61574}
The main change here is that in isolate-data.h, I'm switching from stateJSON to state.
This routine returns a CBOR encoded state cookie, which is also what we already
use in Chromium (blink).
In inspector-test.cc, I then put this byte vector into a V8 String,
and to make this roundtrip, change the extraction routine to get the
bytes. It's a little weird to store arbitrary bytes inside a v8 string,
but it appears to work fine because these bytes end up in the 8 bit portion,
much like isolatin characters would.
Change-Id: I72a0bdefd85a290f4e91db79be67d86952831685
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1610478
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61544}
They are added under the global scope object, as follows:
{
"memory": ...,
"globals": {
"global#0": ...,
"global#1": ...,
"global#2": ...,
}
}
We currently don't have any way to name globals in the wasm binary
format, but it is possible to extend the name section with these names
in the future.
Bug: v8:6846
Change-Id: I79fa4ed3d83964bc8e26d66516605d41e92b3d03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601829
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61425}
There are two possible type:
- scriptParsed - breakpoint for any script,
- scriptWithSourceMapParsed - breakpoint for script with
sourceMappingURL.
When one of the breakpoints is set then for each matched script
we add breakpoint on call to top level function of that script.
Node: https://github.com/nodejs/node/issues/24687R=dgozman@chromium.org
Bug: chromium:887384,chromium:724793,chromium:882909
Change-Id: I9c08b2a2a5ba7006adfedd85fc92ae191517af00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1354245
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61353}
Our {Vector} template provides both {start} and {begin} methods. They
return exactly the same value. Since the {begin} method is needed for
iteration, and is also what standard containers provide, this CL
switches all uses of the {start} method to use {begin} instead.
Patchset 1 was auto-generated by using this clang AST matcher:
callExpr(
callee(
cxxMethodDecl(
hasName("start"),
ofClass(hasName("v8::internal::Vector")))
),
argumentCountIs(0))
Patchset 2 was created by running clang-format. Patchset 3 then
removes the now unused {Vector::start} method.
R=jkummerow@chromium.orgTBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
Bug: v8:9183
Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61081}
This tests calling Debugger.getPossibleBreakpoints on a user function
embedded into the startup snapshot.
Currently, this fails because inspector does not know how to handle
scripts without an associated context. The test should be updated
once we have a fix.
Bug: v8:9029
Change-Id: Id2391a2df203fa7f119f39ea1c34da6a7c54206f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581643
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61063}
This is a reland of 067ba2a0c6.
Unchanged reland, hence TBR.
Original change's description:
> [wasm] Add stack guard for logging code
>
> Benchmarks or worker threads might never return to the event queue,
> hence they will never execute the scheduled foreground task to log
> compiled and published wasm code.
> This CL adds a stack guard to log the code, to ensure that we also log
> it for wasm code that never returns to the event queue.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:9104
> Change-Id: I176959cadb4ab3a60153d0717530c032272ad3e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561073
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60879}
TBR=mstarzinger@chromium.org
Bug: v8:9104
Change-Id: I105b37ef8429d16ef5b983919ba8bca615e347c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1570017
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60899}
Benchmarks or worker threads might never return to the event queue,
hence they will never execute the scheduled foreground task to log
compiled and published wasm code.
This CL adds a stack guard to log the code, to ensure that we also log
it for wasm code that never returns to the event queue.
R=mstarzinger@chromium.org
Bug: v8:9104
Change-Id: I176959cadb4ab3a60153d0717530c032272ad3e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561073
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60879}
Instead of having sequential compilation implemented as a separate
path, we can just use the existing parallel compilation path, and
restrict the number of parallel compilations (if deterministic
compilation is required).
R=mstarzinger@chromium.org
Bug: v8:9104
Change-Id: Ia12c6e45455834a131b3d2ed55f5fe9132903d8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552782
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60740}
The test is working since some time. It was blocked on the jump table,
and patching it correctly when redirecting imported functions to the
interpreter.
R=mstarzinger@chromium.org
Bug: v8:7767
Change-Id: Id3a16de9c6403cab0321958b681ff18f216fe978
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559852
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60716}
Reading --verify_predictable makes me sad, whereas --verify-predictable
makes me happy. This CL introduces more happiness.
R=machenbach@chromium.org
Bug: v8:8834
Change-Id: Id51a75f32e6d5a2f87aed81e058a8b6dff189758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550399
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60599}
