This CL refines https://crrev.com/c/3829539 to only apply to let and
const declared variables. `var`s should stay `undefined`.
R=jarin@chromium.org
Bug: chromium:1328681
Change-Id: I35778c89fb04439348a4f6aebcdeb2db6234f9d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3848960
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82640}
When a string is in a local or on the value stack at a breakpoint,
DevTools should be able to show its value.
Bug: v8:12868
Change-Id: I79014d74c8ef7b212469382bdedca85568b3bcc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3834038
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82542}
This CL fixes a CHECK that checks the wrong thing. Specifically when
we `Advance` the debug::PropertyIterator it can throw an exception.
We have a CHECK that verifies that a corresponding v8::TryCatch catches
the exception when the return value indicates this. Unfortunately, the
CHECK was looking at the wrong v8::TryCatch scope.
R=jarin@chromium.org
Bug: chromium:1353051
Change-Id: Ic52e4efd44b89f8e4d1f6acace234c6065e081cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829543
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82489}
Consider the function:
function foo() {
debugger;
let y = 1;
}
V8 will elide the hole initialization for 'y'. When we pause at the
debugger statement, then 'y' evaluates to 'undefined'.
This CL fixes this in the ScopeIterator. When we encounter local
variables with an `undefined` value we check the static scope
information if we are stopped *before* the variable's initializer.
If yes, then we are in the variable's TDZ and report
"value unavailable".
Drive-by: Mark `GetSourcePosition()` as `const` to make it available
in the visitor method.
R=bmeurer@chromium.org
Bug: chromium:1328681
Change-Id: I8b966eaa2af64a35a58095a744440851760921a0
Fixed: chromium:1303493
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829539
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82483}
This CL builds upon https://crrev.com/c/3284887 (and partly reverts it).
Class literals are a bit iffy when it comes to source position and
debugging. Mainly the debugger assumes the following invariant:
When we are paused inside a class scope, then we expect the class's
BlockContext to be pushed already. On the other hand, when we are
paused outside a class scope in a function, we don't expect to find
the class's BlockContext.
The problem is that there are cases where we can either pause
"inside" or "outside" the class scope. E.g.:
* `var x = class {};` will break on `class` which is inside
the class scope, so we expect the BlockContext to be pushed
* `new class x {};` will break on `new` which is outside the
class scope, so we expect the BlockContext to not be pushed
yet.
The issue with the fix in https://crrev.com/c/3284887 is that it
adjusted the break position for the bytecode of class literals to
ALWAYS be after the BlockContext is pushed. This breaks the
second example above. We need to tighten the fix a bit and only
defer the break position if the "current source position" is
inside the class's scope. This way we always guarantee that the
BlockContext is pushed or not, depending if the source position
that corresponds to the break position is inside or outside the
class's scope.
Note 1: The CL updates a lot of the bytecode expectations. This
is because the class literals are often the first statement in
the snippet so we don't need to defer the break position.
Note 2: We add a mirrored debugger test to the inspector test so
the fuzzer can have some more fun.
Fixed: chromim:1350842
Change-Id: I9b5a409f77be80db674217a685a3fc9f8a0a71cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827871
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82473}
This CL removes the bailout when trying to collect the scope info
for the class member initializer function. While this might not have
worked previously, now we only need to tweak the scope search
slightly to fix this. Class member initializer functions never
have their own context but instead us the class context. That means
that most of the logic in debug-scopes.cc doesn't really matter and we
only need to initialize the ScopeIterator properly with the class
context and the member initializer JSFunction.
Note that this still does not fully fix bug 1350842. That is because
we still run into a DCHECk when paused at a `new class { ... }`
statement. We'll fix that in a separate CL.
R=bmeurer@chromium.org
Bug: chromium:1350842
Change-Id: Id128b10676a5aa8a77309735e755e485f2c14446
Fixed: chromium:1246889
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825881
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82387}
We have a bug report from 2018 that no longer reproduces on ToT.
This CL adds a regression bug regardless to make sure we don't
re-introduce the bug that got fixed as a side-effect.
R=kimanh@chromium.org
Fixed: chromium:1246896
Change-Id: I8f9fdcbf7051b23e03cbbfc572771a410f70ad37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3822668
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82372}
This CL adds a small inspector test to verify that Runtime.evaluate
with silent on/off can be interleaved while replMode is true for all
evaluations.
This is to check that the interaction between console and live
expressions works as expected when the user enables
"Pause on exceptions".
R=bmeurer@chromium.org
Bug: chromium:1335439
Change-Id: Iebd3f9f207312dc6dcd3d0b9a8483ef09608528f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3822685
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82337}
This CL fixes a crash when we build the scope chain after re-parsing
for Debugger.evaluateOnCallFrame.
The following script causes the crash:
class A {
test(){
debugger;
}
f = (x) => {}
}
let a = new A()
a.test()
The current scope search tries to be smart and descends deeper
into the scope tree based on source position. That is not a sound
approach as V8 doesn't guarantee that sibling scopes don't overlap.
In the above case V8 creates an instance initializer scope where
f is assigned (and the initializer scope is the parent scope for
the arrow function). The problem is that the initializer scope
uses the same source range as the class `A` itself, so when we
look for the scope for `test`, we descend wrongly into the
initializer scope and can't recover.
The solution is to not try and be too smart:
- First, find the closure scope with a straight-up DFS.
- Once we have that, descend from there and try to find the
closest fitting scope around the break position.
R=bmeurer@chromium.org, jarin@chromium.org
Bug: chromium:1348186
Change-Id: Ic5e20c4d12b3d768f76a17367dc0f87bcc73763b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807594
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82216}
This is a reland of commit 491de34bcc
co-authors: Ji Qiu <qiuji@iscas.ac.cn>
Alvise De Faveri Tron <elvisilde@gmail.com>
Usman Zain <uszain@gmail.com>
Zheng Quan <vitalyankh@gmail.com>
Original change's description:
> [riscv32] Add RISCV32 backend
>
> This very large changeset adds support for RISCV32.
>
> Bug: v8:13025
> Change-Id: Ieacc857131e6620f0fcfd7daa88a0f8d77056aa9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736732
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
> Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82053}
Bug: v8:13025
Change-Id: I220fae4b8e2679bdc111724e08817b079b373bd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807124
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82198}
This very large changeset adds support for RISCV32.
Bug: v8:13025
Change-Id: Ieacc857131e6620f0fcfd7daa88a0f8d77056aa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736732
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82053}
After some solid bike shedding, we decided to rename one part of the
API.
R=jarin@chromium.org
Bug: chromium:1334585
Change-Id: Ie967f9f4947b2c328433e4c4a9d748ad15ae7175
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788095
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81987}
The intial version of the API was replaced with a more ergonomic one
recently.
We can also safely remove the test as the new API guarantees that
tasks are always finished and cancelled.
Bug: chromium:1334585
Change-Id: I9ff8b92fcd73ef821c86de52c40a1d04b15ea918
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780539
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81950}
The DevTools frontend doesn't want the Wasm module's understanding of
function body offsets (i.e. including locals), but the ranges of
offsets where breakpoints can be set (i.e. only where instructions are).
This patch adjusts the reported offsets accordingly.
A consequence is that we have to report full (start,end) pairs for each
function, instead of being able to dedupe end1==start2 etc.
Bug: v8:12917
Change-Id: I0c7d2d96435cdac2c4553647b7bcc8783bc1798b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780526
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81887}
This CL adds a new method to the `console` that is available
when DevTools is open. In TypeScript notation the API is:
```
namespace console {
// Creates a new `Task` and associates the current async
// stack trace with the created `Task`.
scheduleTask(name: string): Task;
}
interface Task {
// Executes an arbitrary payload and forwards the return value
// back to the caller. Any async stack trace captured during
// 'f' has the site of the corresponding `scheduleTask` as
// its parent.
run<T>(f: () => T): T;
}
```
The API is a saner user-facing API for our async stack trace
mechanism:
* scheduleAsyncTask corresponds to scheduleTask
* startAsyncTask/stopAsyncTask are called implicitly before `f`
is executed.
* cancelAsyncTask is called implicitly when `Task` is GC'ed
The API is behind the flag --experimental-async-stack-tagging-api
Bug: chromium:1334585
Change-Id: Ic6054279a108756caed6b4b5f2d1fe4a1bdbaf78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776678
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81881}
- Removed duplication and unnecessary indirection from all suites testcfgs.
- Introduced a more comprehensive context to cover both command context and other platform specific concerns.
- Propagated above context to TestLoader to allow for test counting command execution on all platforms.
- Wrapped original pool with another class to give it a new interface and allow injecting different implementations in the future.
- Consolidated progress indicators under a single processor in the pipeline.
- Consolidated result retention requirements calculation outside of pipeline chain.
- Refactored LoaderProc and got it under tests.
- Added some more tests for the standard runner.
- Extracted BuildConfig class.
Bug: v8:12785
Change-Id: I87be040e91f792a983662bb5a10d55b36a14ea7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3701595
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81770}
As sandboxed pointers are now default-enabled when the sandbox is
enabled, it is no longer possible to deactivate the sandbox at runtime.
This CL therefore removes all the logic that was required to support a
sandbox that could be disabled at runtime, moves the initialization of
the sandbox into V8::Initialize, and deprecates V8::InitializeSandbox.
This change also makes the sandbox initialization deterministic if
FLAG_random_seed is supplied.
Bug: v8:10391
Change-Id: Ibd49f7c251b7c58c642f18a551ecc2c391740970
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762583
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81746}
The streaming decoder did not properly check the ordering of sections
relative to the code section.
This CL fixes that for both empty and non-empty code sections.
The special path for empty code sections is not actually needed, so
remove it to simplify code paths.
Drive-by:
1. Refactor the existing code for checking section ordering to make it
more structured and readable.
2. Ensure that we either call {DecodeCodeSection} or {StartCodeSection},
but not both.
3. Remove {set_code_section}, merge it into {StartCodeSection}.
4. Simplify calls to {CalculateGlobalOffsets} (make them unconditional
and remove one redundant one).
R=ahaas@chromium.org
Bug: chromium:1336380
Change-Id: Ia2c5c115d43d2b5315e3b3c9e4a21175a36aa326
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3747860
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81554}
This adds a new --experimental-value-unavailable flag, which is disabled
for now. When enabled the debugger reports values that are optimized out
by TurboFan and values of certain variables in Temporal Dead Zones (TDZ)
as unavailable. Internally we use a special `value_unavailable` accessor
info to represent these values, and on the debugger boundary we report
these properties with `value`, `get`, or `set`.
Doc: https://goo.gle/devtools-value-unavailable
Bug: chromium:1328681
Demo: devtools-dbg-stories.netlify.app/crbug-1328681-value-unavailable
Change-Id: Idb09a4a148335a950deae60f7c07caecc48826ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3627510
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81509}
This is a reland of commit dac6155649
This is a straight-up reland with no changes, because:
1) The failure doesn't reproduce locally
2) The failing flaky test that triggered the revert is not related
to the code modified by this CL and should (in theory) not be
impacted.
Original change's description:
> [inspector] Allow Debugger.setScriptSource to edit top-most function
>
> This CL adds a new boolean flag on the Debugger.setScriptSource CDP
> method that gets piped all the way through to the live-edit mechanism.
> The new flag enables live-editing of the top-most function while
> paused.
>
> The CL adds a couple of tests that cover the new core use cases for
> this flag.
>
> R=jarin@chromium.org
>
> Bug: chromium:1334484
> Change-Id: I12fec591b2b6550d89748714620e629548e1b9c1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695354
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81127}
Bug: chromium:1334484
Change-Id: I9a9bf7e03d81c86adb4819b9756dd9afcf6fa021
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3706398
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81171}
This reverts commit dac6155649.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/9288/overview
Original change's description:
> [inspector] Allow Debugger.setScriptSource to edit top-most function
>
> This CL adds a new boolean flag on the Debugger.setScriptSource CDP
> method that gets piped all the way through to the live-edit mechanism.
> The new flag enables live-editing of the top-most function while
> paused.
>
> The CL adds a couple of tests that cover the new core use cases for
> this flag.
>
> R=jarin@chromium.org
>
> Bug: chromium:1334484
> Change-Id: I12fec591b2b6550d89748714620e629548e1b9c1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695354
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81127}
Bug: chromium:1334484
Change-Id: I165269d6c1b001b516f10ae3716ffb57b675ab39
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3705378
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Owners-Override: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81130}
This CL adds a new boolean flag on the Debugger.setScriptSource CDP
method that gets piped all the way through to the live-edit mechanism.
The new flag enables live-editing of the top-most function while
paused.
The CL adds a couple of tests that cover the new core use cases for
this flag.
R=jarin@chromium.org
Bug: chromium:1334484
Change-Id: I12fec591b2b6550d89748714620e629548e1b9c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695354
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81127}
This CL introduces a new `status` enum returned by setScriptSource.
We'll use the information in the DevTools frontend to show more
meaningful error messages as well as disambiguate compilation errors
from failed live edits.
Drive-by: Deprecate the sync and async stack traces in the result.
Currently `setScriptSource` is guaranteed to stay paused so there
is no need to send along the same information from the
preceeding `Debugger.paused` event.
In the future we will restart the top-most frame once we allow
the top-most frame to be edited. In that case the inspector
fires Debugger.resumed + Debugger.paused events following the
live edit also making the info returned here superfluous.
R=jarin@chromium.org
Bug: chromium:1334484
Change-Id: I4226491caed72013a00927273c523213d797a766
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3691850
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81031}
This CL fixes an issue with async stacks. The async task stack is not
torn down between page navigations or reloads. The result is that
any new async tasks are stacked on top of the old pages async task
stack.
This was not prominent until now for two reasons:
1) Async tasks created in blink are always finished as long as
destructors have time to run.
2) When V8 is terminated while running the micro task queue also
all async tasks created for Promises (including `await`) are
cleaned up properly.
Introducing the stack tagging API made it more common for having
unfinished async tasks open outside the MTQ, which left the
async task stack non-empty during navigation.
This CL fixes this problem by clearing out all the async task
and async stack data structures for a context group when that
context group is reset.
R=bmeurer@chromium.org, victorporof@chromium.org
Fixed: chromium:1328785
Change-Id: Iee0c3c4a55f66e643829dae3726dc03c735da1dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3666620
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80741}
This CL fixes a wrong assumption in the LiveEdit machinery. Namely
the assumption that every FunctionLiteral the parser finds, will have
a corresponding SFI created by the compiler. This assumption does not
hold in all cases. Inner functions that are never referenced by the
outer function don't get an SFI.
R=bmeurer@chromium.org
Fixed: chromium:1328453
Change-Id: I674f023f948954c1fcae04a4aa2afb69ea1642aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663443
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80735}
Part of the improve error messages initiative.
Based on a resource of JSON.parse() errors found at
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/JSON_bad_parse
Previously JSON.parse(NaN) would output:
SyntaxError: Unexpected token N in JSON at position 0
Now the output is:
SyntaxError: "NaN" is not valid JSON
Previously JSON.parse("{a:1}") would output:
SyntaxError: Unexpected token a in JSON at position 1
Now the output is:
SyntaxError: Expected property name or '}' in JSON at position 1
Bug: v8:6551
Change-Id: Ic9fad1fdbd295e1302805b81e6603fc526121960
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3513684
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Issack John <issackjohn@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80567}
This is a reland of commit 8278cb5015
The reland adds the RestartFrameTrampoline to the list of
builtins that the deoptimizer is allowed to return from for
control flow integrity.
Original change's description:
> [inspector] Re-enable Debugger#restartFrame
>
> Doc: https://bit.ly/revive-restart-frame
>
> This CL "undeprecates" Debugger#restartFrame and adds a new optional
> "mode" parameter for back-wards compatibility. Moreover, the return
> values are all deprecated. They were never actually used in the
> DevTools frontend and the same information is available from the
> Debugger#paused event that fires once execution stops at the
> beginning of the restarted function.
>
> The CL also re-baselines all the restart-frame inspector tests that
> now run successfully.
>
> R=bmeurer@chromium.org, kimanh@chromium.org
>
> Bug: chromium:1303521
> Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80491}
Bug: chromium:1303521
Change-Id: I13e2f8b5011795a38e541310622b8333a3d08049
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644624
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80534}
This is more consistent with similar features, for example
V8_ENABLE_WEBASSEMBLY or V8_ENABLE_MAGLEV.
Drive-by: remove V8_SANDBOX_IS_AVAILABLE as it's no longer needed.
Bug: v8:10391
Change-Id: I8658c5b0c331a4c73892737083b2c2f9b8f84056
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647355
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Samuel Groß <saelo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80530}
This reverts commit 8278cb5015.
Reason for revert: breaking https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/10778/overview
Original change's description:
> [inspector] Re-enable Debugger#restartFrame
>
> Doc: https://bit.ly/revive-restart-frame
>
> This CL "undeprecates" Debugger#restartFrame and adds a new optional
> "mode" parameter for back-wards compatibility. Moreover, the return
> values are all deprecated. They were never actually used in the
> DevTools frontend and the same information is available from the
> Debugger#paused event that fires once execution stops at the
> beginning of the restarted function.
>
> The CL also re-baselines all the restart-frame inspector tests that
> now run successfully.
>
> R=bmeurer@chromium.org, kimanh@chromium.org
>
> Bug: chromium:1303521
> Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80491}
Bug: chromium:1303521
Change-Id: Ibc33328c31a4b6ea736d07ce5e5ee109039eec8b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3645767
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80495}
Doc: https://bit.ly/revive-restart-frame
This CL "undeprecates" Debugger#restartFrame and adds a new optional
"mode" parameter for back-wards compatibility. Moreover, the return
values are all deprecated. They were never actually used in the
DevTools frontend and the same information is available from the
Debugger#paused event that fires once execution stops at the
beginning of the restarted function.
The CL also re-baselines all the restart-frame inspector tests that
now run successfully.
R=bmeurer@chromium.org, kimanh@chromium.org
Bug: chromium:1303521
Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80491}
To be consistent with the all the other tiers and avoid confusion, we
rename --opt to ---turbofan, and --always-opt to --always-turbofan.
Change-Id: Ie23dc8282b3fb4cf2fbf73b6c3d5264de5d09718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610431
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80336}
When formatting console messages (for consumption in Chromium/Blink), we
have special logic to unwrap value wrapper objects. But this logic was
not very consistent, and especially Number values and NumberObject
values were formatted differently.
This changes the V8ValueStringBuilder::append() logic to always unwrap
any value wrapper first and then use the regular dispatch for the
primitive value.
Fixed: chromium:1321833
Change-Id: I9996671e1f91da0841e5d5f1687cf647ab72a561
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3622913
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80323}
This change adds support for computing SHA-256 hashes in the stack
output of errors by adding a function to the prototype of the
`CallSite` object, passed to `Error.prepareStackTrace`. Additionally,
it updates the `hash` property from `Debugger.scriptParsed` and
`Debugger.scriptFailedToParse` to be SHA-256 instead of the
proprietary hash it is today.
It is intended to be an advancement in indexing source maps to
support improved tooling, especially for post-hoc or in-production
diagnostics scenarios.
The explainer can be found here:
https://docs.google.com/document/d/13hNeeLC2Ve_FVieNndZUUUP15x2O4ltvjnGWwOsMlrU/edit?usp=sharing
Change-Id: Ifbbed4b22c8256e74e6d79974d2dd1e444143eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229957
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Robert Paveza <Rob.Paveza@microsoft.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80320}
We weren't really translating between location (line and column number)
and source position (character offset) consistently, especially when it
came to inline <script>s. There were also inconsistencies between what
Debugger.getPossibleBreakpoints and Debugger.setBreakpointByUrl would
do.
With this CL, we are now consistently operating under the following
assumptions:
(1) For inline <scripts>s with a //@ sourceURL annotation, we assume
that the line and column number that comes in via the protocol is
in terms of the source text of the script.
(2) For inline <script>s without said annotation, we assume that the
line and column numbers are in terms of the surrounding document.
This is finally aligned with how the DevTools front-end operates.
Fixed: chromium:1319828
Change-Id: I98c4ef04b34a97caf060ff4f32690b135edb6ee6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610622
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80292}
If the debug handler (called via {OnDebugBreak}) requests termination of
the isolate, this would only get considered on the next stack check,
where it is turned into a proper termination exception.
Handling this correctly is further complicated by the {DebugScope}
blocking any handling of interrupts via the included
{PostponeInterruptsScope}.
Hence this CL refactors the code to call any debug handlers in a second
function which has the {DebugScope}, and to check for interrupts after
leaving that scope.
R=thibaudm@chromium.orgCC=bmeurer@chromium.org
Bug: chromium:1319343
Change-Id: Ia2df0f2610d50eedc6437841c4bf1d2ad3ac9125
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605228
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80235}
Doc: https://bit.ly/revive-restart-frame
Context: https://crrev.com/c/3582395 (whole feature)
This CL adds a new optional flag `canBeRestarted` to every call frame
in Debugger.paused events. As the name suggests, the flag indicates
whether we can restart a particular frame through Debugger.restartFrame
once implemented.
We are not able to safely restart all frames:
* We don't support WASM frames
* We don't support frames where resumable functions (async fns,
generators) and embedder C++ frames are between the top-most
frame and the to-be-restarted frame.
Note that from a CDP perspective the flag doesn't actually guarantee
a successful restart. CDP clients can issue
CDP commands between the Debugger.paused event and before a user
decides to restart a frame, which can potentially mess
with the stack.
The `canBeRestarted` flag tests are folded into the
Debugger.restartFrame tests. As the feature is not yet fully
implemented we short-circuit most of the tests for now and only
run them up until the first Debugger.restartFrame call fails
(except "fails-for-resumables.js").
This means the tests exercise the `canBeRestarted` flag, but not
the restarting functionality itself.
R=bmeurer@chromium.org, kimanh@chromium.org
Bug: chromium:1303521
Change-Id: I01ab46dc3557ab8383960969fbe03e00604cc5e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596160
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80046}
Doc: https://bit.ly/revive-restart-frame
Context: https://crrev.com/c/3582395 (whole feature)
This CL adds the second batch of inspector tests for the upcoming
"Restart frame" feature. Landing the tests upfront allows us to
better discuss the proposed API as well as think early about
corner cases we should test.
The tests check for the functionality of `Debugger.restartFrame`, as
well as the newly added parameter `canBeRestarted` in
the `Debugger.paused` event.
Bug: chromium:1303521
Change-Id: Ie9dda100cdc5217a4e4cc2f0cf7019a33d124120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585947
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80037}
Doc: https://bit.ly/revive-restart-frame
Context: https://crrev.com/c/3582395 (whole feature)
This CL adds the first batch of inspector tests for the upcoming
"Restart frame" feature. Landing the tests upfront allows us to
better discuss the proposed API as well as think early about
corner cases we should test.
The tests check for the functionality of `Debugger.restartFrame`, as
well as the newly added parameter `canBeRestarted` in
the `Debugger.paused` event.
Bug: chromium:1303521
Change-Id: Ibda6d8b6110fce893e0844f8902fbd5d901ae01d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585946
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80013}
1. Added `generateWebDriverValue` flag to `Runtime.evaluate` and `Runtime.callFunctionOn`.
2. Added `webDriverValue` field to `RemoteObject`, and set it in case of the `generateWebDriverValue` flag was set.
3. Added virtual method `bidiSerialize` to allow embedder-implemented serialization (like in https://crrev.com/c/3472491).
4. Implemented V8 serialization in a separate class `V8WebDriverSerializer`.
5. Hardcode `max_depth=1`.
6. Added tests.
Not implemented yet:
1. `objectId`.
2. Test of embedder-implemented serialization.
Tested automatically by:
```
python3 tools/run-tests.py --outdir out/foo inspector/runtime/add-web-driver-value
```
Naming to be discussed. Suggestions are very welcome.
Design doc: http://go/bidi-serialization
Change-Id: Ib35ed8ff58e40b3304423cc2139050136d844e2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3472077
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Maksim Sadym <sadym@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79922}
