- Use C++ primitives (int, bool) for the ScriptOrigin constructor.
- Deprecate the old accessors and constructor
Bug: v8:11195
Change-Id: I739edd6b4c58e19a8a16ddce863eea14ec933697
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555005
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71384}
We had a test which first enabled the profiler, and then compiled wasm
code. In this case, all code objects were registered correctly and the
profile looked as expected.
This CL extends the test for also test another order: First compile the
wasm code, then enable the profiler. In that case, we were reporting a
wrong debug name of the exported wasm function. The name of that
function is spec'ed to be the string representation of the function
index. But for debugging, we want to see a more meaningful name,
identical to the name we show when reporting the code during
compilation.
This fix requires handlifying the {SharedFunctionInfo::DebugName}
method, because for exported wasm functions, it needs to allocate a new
name on the JS heap.
In order to avoid this allocation where possible, a second variant is
added which returns a unique_ptr directly. This can be used in all
places where the name is just being printed, which turned out to be the
majority of cases ({DebugName().ToCString()}).
R=petermarshall@chromium.org
Bug: chromium:1141787
Change-Id: I0343c2f06f0b852007535ff07459b712801ead01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543931
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71308}
Add a requirement to String::GetChars that we either have a string
access lock, or a string access lock is not needed. This prevents us
from reading strings during internalization that may be in the middle
of being made external.
To avoid taking the lock too often when known to be unnecessary (e.g.
for strings that were only just created), there's now a static
SharedStringAccessGuardIfNeeded::NotNeeded(). This is hopefully ugly
enough that it's used sparingly.
One fix required for this is to enter the Isolate when tearing down
IsolateData in inspector tests -- this is so that the V8Inspector
instance being torn down will see the current Isolate and be able to
verify its thread id against the current thread.
Bug: chromium:1011762, chromium:1148680
Change-Id: Ic5d29c1b066ebae5a351c7b4bb116b9b1bf61889
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536465
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71197}
Currently, we assume that stack trace creation always succeeds while
filling in the `exceptionDetails` structure. Stack trace creation can
fail under some circumstances so this CL introduces a null check.
R=clemensb@chromium.org
Bug: chromium:1147552
Change-Id: I4055d5276bbb7bf178b648bfc7bd84a288626c09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2532310
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71169}
The fuzzer is expected to generate a lot of syntax and runtime errors,
and the respective messages just flood the fuzzer output. By always
putting a {TryCatch} scope around the execution, we prevent those
messages from being printed.
At the same time, inspector tests need to properly propagate uncaught
exceptions in the backend to the inspector, and fail on uncaught
exceptions in the frontend.
This CL allows for all these behaviours by extending the
{CatchExceptions} enum and the {TryCatch} logic in the task runner.
Drive-by: Use {base::OS::ExitProcess} instead of the explicit
{fflush} and {_exit}.
R=szuend@chromium.org
Bug: chromium:1142437
Change-Id: Ic2cb3b0de2399d25bd8c53090575308cb0e09ab0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529135
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71152}
For the fuzzer it's unwise to exit on uncaught exceptions, as this
terminates the whole fuzzing process. Just ignore those exceptions
instead.
Drive-by: Fix a typo.
R=szuend@chromium.org
Bug: chromium:1142437
Change-Id: Ided1c0f35840c158f157acd8c0bb1c12ecf8a37f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526386
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71059}
Instead of passing two bools to the {TaskRunner} constructor, pass to
enums. This makes the semantics more clear in the caller.
In the fuzzer, we actually *do not* want to catch exceptions. This
semantic fix will be done in a follow-up CL, such that this CL is a pure
refactoring.
R=szuend@chromium.org
Bug: v8:11074
Change-Id: I7f6df3a3f344524deb08db10b9317a6734b7ea42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526385
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71056}
Joining the thread from the watchdog is problematic, since e.g.
{pthread_join} (the implementation of {Thread::Join} on POSIX systems)
has undefined behaviour if multiple threads try to join at the same
time. In practice, this leads to deadlocks.
Thus implement termination by just calling {TaskRunner::Terminate}, but
not {TaskRunner::Join}. This fixes the deadlocks in the inspector
fuzzer.
The inspector test binary is fixed simarly, even though there it seems
to not cause problems so far.
In both files, the {Terminate} function is inlined into callers because
it's only a single line now, with one to two users.
Also, replace the single fuzzer test (which is invalid javascript) by
two tests: One called "invalid" explicitly, still with invalid
javascript, and one empty file, which is valid input. That one
reproduced the deadlock.
R=szuend@chromium.org
Bug: chromium:1142437
Change-Id: I8fb98b0cdbf3ceff6af6849397e5da5a4e9acd3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526384
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71054}
Asan complains about the alloc-dealloc-mismatch because the startup data
is allocated via "new[]" in snapshot.cc and deallocated via "delete" in
inspector-test.cc.
A more failure-proof fix would be to have {StartupData} manage the
lifetime of the contained char*, but since this is in an API object, the
refactoring might be more involved. Since other users also just dealloc
explicitly via "delete[]", this CL just fixes the issue in
inspector-test.cc.
R=szuend@chromium.org
Bug: chromium:1142437, v8:11107
Change-Id: I84438b2f12ce8eb6b653d4861e899a2f003e1227
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2523200
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71045}
The {ToV8Vector} method returns a {i::Vector} pointing to heap-allocated
memory, but that memory was never free'd. Since we already have a
{ToVector} method returning a {std::vector}, this CL switches to that
one instead.
R=szuend@chromium.org
Bug: chromium:1142437, v8:11107
Change-Id: I8ee0177f7dcfe2ecb435e684674b0cda6f613658
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2523198
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71040}
Rename the field "deffered_queue_" to "deferred_queue_".
R=szuend@chromium.orgCC=yangguo@chromium.org
Bug: chromium:1142437
Change-Id: I004082b7a798c8b7df92c7adea32e71cb11d7bef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2520899
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71009}
While writing a new test I realized that the test did not fail if
running into a CHECK or UNREACHABLE *after* printing the last expected
line.
That is because both stderr and the exit status are ignored. This CL
fixes that.
This will uncover a lot of memory leaks, which I plan to address in
follow-up CLs.
R=machenbach@chromium.org
CC=szuend@chromium.org
Bug: chromium:1142437, v8:11107
Cq-Include-Trybots: luci.v8.try:v8_linux64_asan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_asan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_win64_asan_rel_ng
Change-Id: I65f325abf102e063bb4f449353c47e94d84de652
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519567
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71006}
Keep tasks in unique_ptrs, such that they are freed independent of
whether they have been executed or not.
R=szuend@chromium.org
Bug: chromium:1142437, v8:11107, v8:11074
Change-Id: Ia265df3187c724b63e0f576d33235c1bfa522c4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2517694
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71005}
The inspector fuzzer is running into timeouts most of the time
currently, because the test explicitly needs to quit execution.
Make fuzzing more efficient by adding a watchdog thread which stop
execution after 2 seconds. This will still result in valid test cases,
i.e. everything that was executed within those two seconds will count as
covered code.
Drive-by: Slightly simplify the storage of task runners. No need to
clear the vector after termination.
R=szuend@chromium.org
Bug: chromium:1142437, chromium:1145285
Change-Id: I7b5fe7ddcbce731fbc3d74ee8c43f7249f34b918
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2520906
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71002}
Calling {Exit} does not stop execution in the current thread (or
process), it just tells the two task runners to stop. Hence following
code would still be executed.
This CL replaces the calls to {Exit} to {FATAL} for internal errors
where we want to stop immediately.
R=szuend@chromium.org
Bug: chromium:1142437
Change-Id: I70c1c39da28a3cd040214d46eddf61f05a12bce7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519568
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70984}
This adds a first simple version of the inspector fuzzer, which is a
stripped-down version of the inspector-test executable. The fuzzer
generates inputs which are compatible with inspector-test.
There are still memory leaks, and the fuzzer will probably run into
timeouts most of the time. Both of this will be addressed in follow-ups.
R=szuend@chromium.org, machenbach@chromium.org
Bug: chromium:1142437
Change-Id: I4d13da460f571d791a3642b0705a1f07b442c11b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505722
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70922}
This also extracts the {FrontendChannelImpl}, the {SetTimeoutTask}, and
the {SetTimeoutExtension} for reuse by the inspector fuzzer.
R=szuend@chromium.org
Bug: chromium:1142437
Change-Id: I75e49d6fbb4b801ace1ffc9cac963d6b83c52f36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505717
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70909}
Building these objects takes a lot of time and memory for realistic
applications and exposing them via the Scope view in DevTools isn't
practical either. We have a replacement in the Console now, and if
this needs more exposure we can think about other, more scalable
ways with better UX.
Fixed: v8:10986
Bug: chromium:1141781
Change-Id: I6177d63a987749889a9880cf0738031191eb5705
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507696
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70894}
This CL extracts some functionality from inspector-test.cc to be reused
by the inspector fuzzer.
It also puts all functions in the v8::internal namespace, and adds
separate functions in v8::internal to be called by ::main such that
we have direct access to the full namespace there.
R=szuend@chromium.org
Bug: chromium:1142437
Change-Id: I671317822bdc1c721334469811893affcc460f8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2501847
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70821}
The crash scenario is as follows:
1) Add a getter for 'then' to the Object prototype that is
considered side-effecting.
2) Evaluate a simple string using 'REPL' mode with side-effect checks
enabled.
Note: REPL mode is not strictly necessary, but it causes a 'then'
lookup as the evaluation result is not a promise.
3) Calling the 'then' getter causes a termination exception, due
to the side-effect check. JSPromise::Resolve then tries to
put the termination exception as the reject reason, which causes
a CHECK failure.
The solution is to check for termination in the "abrupt completion"
case when 'then' was retrieved.
Bug: chromium:1140845
Change-Id: I72b644cd49355cea40f599fcbe80264e99ed7bd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2501283
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70785}
This is a reland of 8f7e915839
Original change's description:
> [debugger] Try to trigger pause-on-oom flakes with an extra printf
>
> We have an issue that we can't repro locally. Enable back the
> pause-on-oom tests with an extra printf with DEBUG. We will be able to
> better assess the failures when they appear on the bot.
>
> Bug: v8:10876
> Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70558}
Bug: v8:10876
Change-Id: Ice31c9455830da320ab057293c341f69e1f0c510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484799
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70643}
This changes remoteObjectId format from
"{injectedScriptId:123,id:456}" to "<isolateId>.<contextId>.<id>".
Prepending isolateId fixes the problem that
remote object ids clash between processes. This is especially
troubling during cross-process navigation in Chromium, see bug.
We also stop producing and parsing unnecessary json for object ids.
Drive-by: fixed some tests dumping object ids. Most tests avoid
dumping unstable values like ids, but there were few that still did.
BUG=chromium:1137143
Change-Id: Ia019757fb95704ccb718d3ea6cc54bde1a133382
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461731
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70592}
It makes inspector tests a lot more readable if the opcode of the pause
location is being printed. Since we already have a list of all opcodes
available in wasm-module-builder.js, we can just reuse that to build a
reverse lookup map.
This CL implements this for single-byte opcodes only, which is enough
for all tests that we currently have. It will have to be extended for
prefixed opcodes once that is being used.
R=thibaudm@chromium.org, kimanh@chromium.org
Change-Id: I085fea99d2f5f2dc6cc084448e5f7444cce5c78b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474789
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70578}
This reverts commit 8f7e915839.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20node.js%20integration%20ng/10707?
Original change's description:
> [debugger] Try to trigger pause-on-oom flakes with an extra printf
>
> We have an issue that we can't repro locally. Enable back the
> pause-on-oom tests with an extra printf with DEBUG. We will be able to
> better assess the failures when they appear on the bot.
>
> Bug: v8:10876
> Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70558}
TBR=rmcilroy@chromium.org,petermarshall@chromium.org,solanes@chromium.org
Change-Id: I1b8a146d9496e889957636456b383f8d496658dc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10876
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479004
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70559}
We have an issue that we can't repro locally. Enable back the
pause-on-oom tests with an extra printf with DEBUG. We will be able to
better assess the failures when they appear on the bot.
Bug: v8:10876
Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70558}
... at function start. Otherwise we run into a position mismatch:
In a non-flooded function, we add the function-entry breakpoint (for
"hook on function call") with the position of the first opcode.
In the flooded function though, we skip that special breakpoint because
we will stop at the first instruction anyway. But then the first
instruction is non-breakable, so we don't actually emit a breakpoint for
it.
Hence during OSR we do not find a corresponding position in the new
code.
This CL fixes this by postponing the function-entry breakpoint until the
first breakable opcode is found, and only emits it if that position does
not have a breakpoint anyway.
This way, we can also move the handling for function-entry breakpoints
from {StartFunctionBody} to {EmitDebuggingInfo}, where it fits much
better.
R=thibaudm@chromium.org
Bug: chromium:1137710
Change-Id: Idfa658fa0897cca89ba5ee3066cd414f68864d06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474774
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70529}
Stepping always happens in Liftoff now, and always by byte offset. Thus
remove the redundant "wasm-stepping-byte-offset" test, which was fully
subsumed by "wasm-stepping-liftoff". Also, rename
"wasm-stepping-liftoff" to "wasm-stepping".
R=thibaudm@chromium.org
Bug: chromium:1137710
Change-Id: Ifb68ce795ecdcbb1f85500dc4be4c2e64d15a9c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474116
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70528}
The call to "GetSpilledRegistersForInspection" was invalidated by the
call to "GetUnusedRegister" a few lines below.
R=clemensb@chromium.org
Bug: v8:10957
Change-Id: I1e0110d9b28ca23a2a8b9ff4b4c39143bfbe5510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466118
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70478}
The generic wrapper will be the baseline variant of the JavaScript-to-
WebAssembly wrapper. Enabling it in the nooptimization variant gives it
test coverage.
R=clemensb@chromium.org
Bug: v8:10701
Change-Id: I37d1f767c61ff70e103d1742ef84f874c3804d7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461240
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70472}
Other WebAssembly tools like wabt and wasmparser ignore empty strings
for local variable and parameter names, and just generate their own
names for it. Update V8 to comply with this convention.
Bug: chromium:1134531
Change-Id: Ic724482d93398feaf6b0797eec5a55f8ca508ca5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448457
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70305}
Run variant stress_concurrent_allocation in debug mode and with TSAN.
Failing tests will close tree and block CQ.
Bug: v8:10315
Change-Id: I0ba2921a3718a08b88516f209364b52c8817c331
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436343
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70299}
This adds support for injecting binding into contexts other than
main based on the context name (AKA isolated world name in Blink
terms). This would simplify a common use case for addBinding in
Puppeteer and other automation tools that use addBinding to expose
a back-channel for extension code running in an isolated world by
making bindings available to such code at an early stage and in a
race-free manner (currently, we can only inject a binding into
specific context after the creation of the context has been reported
to the client, which typically introduces a race with other evals
the client may be running in the context).
Change-Id: I66454954491a47a0c9aa4864f0aace4da2e67d3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440984
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70266}
... when addBinding is called with contextId. Previously, due to
a subtle type, we exposed bidings added with executionContextId to
all contexts created after the binding was added.
Also, do not persist context-specific bindings to agent state,
as context ids don't make sense across the process.
This also adds a test instrastructure to create additional context in
given context group.
Change-Id: I1b3e96cb65b756424bc7872d200bbbf41e4c30b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440982
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70261}
Since the inspector/debugger/wasm-scope-info* tests need simd128,
but not all mips cpus support it, we skip the tests on mips
platforms without simd support.
Change-Id: Iebefa5d6b33d80d707ad0077be7d4f25e3e52b4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2439769
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70216}
A break may cause the session disconnect (and therefore agents destruction)
on a nested message loop. The runtime agent code is generally prepared to
handle this during evaluate, but the code outside of it may be not. Besides,
having a break before the console API installed is generally not what
user wants or expects, so just disable all breaks while installing the API.
Bug: chromium:1122487
Change-Id: I1d40f5007f2e1e4ec07a50ef57988513d0309b7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2437383
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70209}
The compilation cache doesn't know about REPL mode. This means that
non-REPL mode compiled scripts are successfully found for their
REPL mode equivalent and vice versa.
This CL disables the compilation cache for REPL mode scripts.
Performance is not really a concern as DevTools console inputs
are usually very small.
R=leszeks@chromium.org
Bug: chromium:1108021
Change-Id: If396c7aa004188730762e4f6bd01dae2fc141181
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434333
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70160}
For now, V128 values are converted to String16 (since they are not
serializable). It is shown as a list of 16 uint8_t (hex). This
description can be tweaked as necessary.
Some updates to ARM64 required to push/pop the full Q register.
Bug: v8:10347
Bug: chromium:1130474
Change-Id: I1bffbb49f47c06da3cd26d830addae0416a4441a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422082
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70096}
This is a reland of 0ba115e6a9
Changes compared to last reland:
- Fix Python code trying to write to expected_outcomes, which is now a
computed property.
- Fix remaining place in d8.cc that ignored the --fuzzing flag.
- Expect flag contradictions for --cache in code_serializer variant.
Original change's description:
> Reland^3 "[flags] warn about contradictory flags"
>
> Changes:
> - Also allow second parameter influenced by --cache to be reassigned.
> - Fix --stress-opt to only --always-opt in the last iteration as before.
>
> Original change's description:
> > Reland^2 "[flags] warn about contradictory flags"
> >
> > This is a reland of d8f8a7e210
> > Change compared to last reland:
> > - Do not check for d8 flag contradictions in the presence of --fuzzing
> > - Allow identical re-declaration of --cache=*
> >
> > Original change's description:
> > > Reland "[flags] warn about contradictory flags"
> > >
> > > This is a reland of b8f9166664
> > > Difference to previous CL: Additional functionality to specify
> > > incompatible flags based on GN variables and extra-flags, used
> > > to fix the issues that came up on the waterfall.
> > >
> > > This also changes the rules regarding repeated flags: While
> > > explicitly repeated flags are allowed for boolean values as long
> > > as they are identical, repeated flags or explicit flags in the
> > > presence of an active implication are disallowed for non-boolean
> > > flags. The latter simplifies specifying conflict rules in
> > > variants.py. Otherwise a rule like
> > >
> > > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > > "--gc-interval=*": ["--gc-interval=*"],
> > > }
> > >
> > > wouldn't work because specifying the same GC interval twice
> > > wouldn't actually count as a conflict. This was an issue with
> > > test/mjsunit/wasm/gc-buffer.js, which specifies
> > > --gc-interval=500 exactly like the extra flag by the stress bot.
> > >
> > > Also, this now expands contradictory flags checking to d8 flags
> > > for consistency.
> > >
> > > Original change's description:
> > > > [flags] warn about contradictory flags
> > > >
> > > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > > >
> > > > Bug: v8:10577
> > > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#68168}
> > >
> > > Bug: v8:10577
> > > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68989}
> >
> > Bug: v8:10577
> > Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69339}
>
> Bug: v8:10577
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Change-Id: I4a69dc57a102782cb453144323e3752ac8278624
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69433}
Change-Id: Ib6d2aeb495210f581ac671221c265df58e8e5e70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398640
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69954}
Instead of using SKIP (which would skip the tests), we can use
[PASS, FAIL] which signals to run the tests and accept if they are
flakily passing. In this way, we would get coverage and an error if we
have a non-flaky failure.
Bug: v8:10876
Change-Id: Idbdf9dcb76775cf5e81dc1c3bc6d9abb1db23ced
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401424
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69790}
