This CL explicitly encodes the 'other' reason for breaking for:
* regular breakpoints
* triggered pause events.
The reason for explicitly encoding the reason is that we may otherwise
not know why we pause when we handle it. This knowledge is needed
in order to fully support instrumentation breakpoints, e.g. if we do
not know that we paused on a triggered pause, and this happens to
overlap with an instrumentation, we would previously only report
'instrumentation' as a reason which would be wrong.
Bug: chromium:1229541
Change-Id: I93c08f965a491f6d34f280157b182a78d5b3cf07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289638
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77970}
In assignments the lhs should be evaluated first and shouldn't be
re-evaluated when the value of the rhs is available. Fix it by
saving the receiver and the key registers into AssignmentLhsData
before building the assignment and use them later, instead of visiting
the AST again to retrieve the receiver.
In addition, now that we save the receiver register, use it to
perform the brand check even when we know for sure that it's
going to fail later because it's a write to a private
method or accessing the accessor in the wrong way (v8:11364),
so that the brand check error always appears first if it is present,
as specified in
https://tc39.es/proposal-private-methods/#sec-privatefieldget
Drive-by: unify the brand check error messages, and replace "Object"
with "Receiver" in the messages for clarity. The instance private
brand check now throws "Receiver must be an instance of class <name>"
and the static private brand check now throws "Receiver must be
class <name>". Also always set the expression position to the
property load position, because the brand check failure comes from
the load operation.
Bug: v8:12352, v8:11364
Change-Id: I61a8979b2e02b561dd5b2b35f9e0b6691fe07599
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266964
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77797}
This reverts commit f9ebad0119.
Reason for revert: suspected root cause of crbug.com/1257806 Additionally, this patch might actually be incorrect as we eagerly evaluate native accessors, which can only happen if the debugger is running.
Original change's description:
> [inspector] Use side-effect free debug evaluate for inherited accessors.
>
> Replace the hard-coded blocklist ("Response.body" and "Request.body") in
> the V8 inspector with proper side-effect free debug evaluate. This is
> otherwise a non-functional change and in particular preserves the
> behavior of reporting accessors as (own) data properties. That will be
> tackled in a follow-up CL.
>
> This CL is possible because with https://crrev.com/c/3056879 Blink now
> properly marks accessors as side-effect free consistently with what the
> V8 inspector had done before.
>
> Doc: http://doc/1gLyyOlssS5zyCSEyybVC-5sp0UnNJj2hBoFyf6ryrTc
> Bug: chromium:829571, chromium:1076820, chromium:1119900
> Change-Id: Idb256accaf4cfb5db5982b3eb06ddcef588be635
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3062573
> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
> Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76019}
Bug: chromium:829571, chromium:1076820, chromium:1119900, chromium:1257806
Fixed: chromium:1265372
Change-Id: Ia31a3022aaa9ddeae1f01eaa90e345f8bdbb21c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259653
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77708}
When evaluating a top-level expression while paused on a breakpoint, we
don't support an await expression as top-level statement. In these
cases, the error was not informative and could be improved.
To do so, we now propagate the information from DebugEvaluate to
ParseInfo and use the parse_info in parser-base to throw a more
informative error while parsing.
R=jarin@chromium.org
Fixed: chromium:1132245
Change-Id: I200c5af7391258256d1d86a09cbcae326327a0d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247037
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77587}
Array spread syntax `[...obj]` is compiled to a special bytecode that
tries to take fast-paths for values special kinds of `obj`s, including
Set, Map, and Array iterator instances. But these fast-paths skip the
side-effect checks of `Runtime.evaluate` and friends, and thus lead to
surprises for developers.
This CL alters the behavior to always call the `next()` builtins when
the debugger is active to make sure we catch the side effects correctly.
Fixed: chromium:1255896
Change-Id: If3fc48a119cfa791c4fde7b5c586acc22dd973e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226329
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77409}
The previous implementation would not explicitly send
`Debugger.paused` events for instrumentation breakpoints
if they were to overlap with breaks due to:
* regular breakpoints
* OOM
* exceptions
* asserts
This CL is a step towards making sure that a separate
`Debugger.paused` event is always sent for an instrumentation
breakpoint. In some cases where we have overlapping reasons
but only know of one, the 'instrumentation' reason,
we still just send out one paused event with the reason
being `instrumentation`.
Drive-by: send instrumentation notification to all sessions,
remember which breakpoints are instrumentation breakpoints
Bug: chromium:1229541, chromium:1133307
Change-Id: Ie15438f78b8b81a89c64fa291ce7ecc36ebb2182
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211892
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77333}
Previously we'd treat %_AsyncFunctionReject (and %AsyncFunctionReject)
as side-effect free (in async functions), but that's not correct, since
promise rejections have side-effects (at the very least triggering the
unhandled promise rejection machinery in the browser).
This required a minor refactoring as previously we'd classify functions
as side-effecting or not depending on whether they contain any calls to
side-effecting intrinsics, no matter whether this call is actually
executed or not. That would break REPL mode however if we'd generally
treat all async functions with %_AsyncFunctionReject intrinsic calls as
side-effecting, so instead of performing the intrinsic checks ahead of
time, we now perform the test at execution time.
Before: https://imgur.com/5BvJP9d.png
After: https://imgur.com/10FanNr.png
Fixed: chromium:1249275
Change-Id: Ib06f945ba21f1e06ee9b13a1363fad342464fd9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197712
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77183}
The V8 Inspector was sending an additional frame as part of async stack
traces for async functions, which pointed to the first executed `await`
in the async function. This is leaking an implementation detail of how
(and more precisely when) the inspector decides to collect this stack
trace. From the users perspective the async part of the stack trace is
supposed to capture what happened _prior to the task_ - meaning in case
of async functions: What lead to the execution of the async function.
This is reflected by the fact that the DevTools front-end (and the V8
Inspector itself) performs post-processing on these async call stacks,
removing the misleading top frame from it. But this post-processing is
not applied consistently to all async stack traces (i.e. the Console
message stack traces don't get this), and potentially also not applied
consistently across consumers of the Chromium debugger backend.
Instead the V8 Inspector now removes the top frame itself and thus
reports `await` consistently with how other async tasks are reported to
debugger front-ends.
Note: This preserves backwards compatibility with old versions of
devtools-frontend, which do post-processing (for the Call Stack) only on
async stack traces marked with "async function", while we now mark these
async stack traces with "await" instead (aligned with what the front-end
is using as user visibile string anyways in the Call Stack section, and
this matching will be updated in a separate follow up CL to look for
"await" instead of "async function").
Before: https://imgur.com/kIrWcIc.png
After: https://imgur.com/HvZGqiP
Fixed: chromium:1254259
Bug: chromium:1229662
Change-Id: I57ce051a28892177b6b96221f083ae957f967e52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193535
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77157}
Previously the internal `[[ArrayBufferData]]` property for `ArrayBuffer`
objects reported by the inspector (and used by the DevTools front-end to
identify `ArrayBuffer`s and `WebAssembly.Memory`s using the same backing
store) simply contained a hex string representation of the backing store
pointer. However that unnecessarily leaks internal addresses and more
importantly is not deterministic, which complicates tests (just blew up
on layout tests).
This CL introduces an automatically incremented `BackingStore::id()`,
which is used instead now and is deterministic.
Bug: chromium:1199701, chromium:1163802, chromium:1249961
Change-Id: I8ee47009cd825cfdbe00230f617c87c90508ab2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162144
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76893}
This reverts commit a4a152ecc5.
Reason for revert: We haven't seen the flakes in a while, we can re-enable functionality
Original change's description:
> Reland "[debugger] Try to trigger pause-on-oom flakes with an extra printf"
>
> 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}
Bug: v8:10876
Change-Id: I901d31e1e92bfef0b2917ea611354618e5cda585
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071404
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76302}
So that it is possible to differentiate modules in the stack trace even
when they are anonymous.
R=kimanh@chromium.org
Bug: v8:11808
Change-Id: I12a1f07accdf62c404052f32624e9914381a7451
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074472
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76141}
For inline scripts that have a `// #sourceURL=foo.js` annotation, the
V8 inspector (and by extension `Error.stack`) currently operates in
terms of the `foo.js`, i.e. doesn't give any hint about the actual
source, except for the line/column offsets reported upon scriptParsed.
However in case of stack frames (i.e. as part of `Error.stack` or as
part of the call frames reported via CDP), the line/column offsets are
relative to the actual source instead of relative to the `foo.js` part,
which - besides other things - makes post-processing of recorded stack
traces tricky (sometimes impossible).
This change adjusts the source positions reported for (inline) scripts
with sourceURL annotations to be relative to the (inline) script instead
of the surrounding document.
Bug: chromium:1183990
Fixed: chromium:578269
Change-Id: I74f2b93c22ec43ca796b6b51faa9df5b99cf03f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069289
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76097}
This is a reland of ce8cef36aa
Original change's description:
> [inspector] Consistently format all native accessors as own properties.
>
> Previously the V8 inspector would only turn embedder accessors on the
> prototype chain into data properties, but would not do the same for
> ECMAScript builtins, which is kind of inconsistent and weird behavior.
>
> This leaves in the hack that the inspector reports native accessor
> properties as (own) data properties, but now at least the very least
> does so consistently. In the absence of a better solution, we'll go
> with this for now.
>
> Bug: chromium:1076820, chromium:1199247
> Change-Id: I593f909a46cb714dbec629a2944eeb892881ba6f
> Before: https://imgur.com/kPuSldj.png
> After: https://imgur.com/eFau45m.png
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067319
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76059}
Bug: chromium:1076820, chromium:1199247
Change-Id: I11987194b0d0b8b250eda4f8ce0ae5fc743eb27c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070701
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76084}
This reverts commit ce8cef36aa.
Reason for revert: broke blink tests: https://ci.chromium.org/ui/p/chromium/builders/try/mac-rel/751822/overview
Original change's description:
> [inspector] Consistently format all native accessors as own properties.
>
> Previously the V8 inspector would only turn embedder accessors on the
> prototype chain into data properties, but would not do the same for
> ECMAScript builtins, which is kind of inconsistent and weird behavior.
>
> This leaves in the hack that the inspector reports native accessor
> properties as (own) data properties, but now at least the very least
> does so consistently. In the absence of a better solution, we'll go
> with this for now.
>
> Bug: chromium:1076820, chromium:1199247
> Change-Id: I593f909a46cb714dbec629a2944eeb892881ba6f
> Before: https://imgur.com/kPuSldj.png
> After: https://imgur.com/eFau45m.png
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067319
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76059}
Bug: chromium:1076820, chromium:1199247
Change-Id: Ib090e0a1dad26f5c9684d906b775555b6a07cca0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069012
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76071}
Previously the V8 inspector would only turn embedder accessors on the
prototype chain into data properties, but would not do the same for
ECMAScript builtins, which is kind of inconsistent and weird behavior.
This leaves in the hack that the inspector reports native accessor
properties as (own) data properties, but now at least the very least
does so consistently. In the absence of a better solution, we'll go
with this for now.
Bug: chromium:1076820, chromium:1199247
Change-Id: I593f909a46cb714dbec629a2944eeb892881ba6f
Before: https://imgur.com/kPuSldj.png
After: https://imgur.com/eFau45m.png
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067319
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76059}
WasmValueObjects used to not have a constructor defined. That prevents
custom devtoolsFormatters from being applied to such objects.
Change-Id: Id775cdb710d0c4106f70858cc1fc92b1f8bd4590
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2991243
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75438}
The test was a bit out-dated, the expected file did not match the test
or the data delivered by V8 anymore. However, all the expected data was
available, so I just adjusted the test accordingly.
R=clemensb@chromium.org
Bug: v8:10356
Change-Id: I1d94f2a295038a4320e07706d46258a278a6dee5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968410
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75222}
This change addresses inconsistencies wrt. to stepping into generator
functions and breaking on the implicit initial yield. The new behavior
is the following:
1. Stepping into a generator function doesn't trigger "generator
stepping", but rather pauses right before the initial yield
(assuming there a no non-simple parameters in between).
2. When paused on the initial yield and stepping into or over, we also
don't turn on "generator stepping" immediately, but rather return to
the caller and only enter "generator stepping" on SuspendGenerator
bytecodes that correspond to `yield`s or `await`s in the source
code.
This matches the stepping behavior of regular functions more closely and
seems like a good compromise.
Fixed: chromium:901814
Change-Id: Ifc6c174011df1afea183e2c6ec21de27d72b17a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949099
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75066}
And also make sure that even long names don't get truncated.
Fixed: chromium:1216284
Change-Id: I2792b60ddeb40a87816cb54fb0414ef0dea45da0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2947409
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75059}
In the Chrome DevTools Protocol, the step actions are named StepOut,
StepOver, and StepInto, but internally we used StepOut, StepNext, and
StepIn instead. This change adjusts the naming to be consistent.
Bug: chromium:901814, chromium:1162229
Change-Id: Id3502a1b0a4aadd94734ec3d1fef73c1782fa220
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928510
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74877}
With this CL, V8 adds an internal field to the WebAssembly Table object
that is sent to DevTools to also show table entries. As WebAssembly
Tables get initialized lazily, V8 only shows the name of the function
instead of the function object itself.
Screenshot before change: https://imgur.com/a/XFvy3lA
Screenshot after change: https://imgur.com/kT84kstR=kimanh@chromium.org
Change-Id: I56a0b07785ff3484f1447419fe39ae5ec3f93247
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897097
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74690}
wasm-scope-info requires SIMD, since it prints the value of the SIMD
value in scope. We skip it using statusfile when SIMD is not supported.
Change-Id: Id64e130a1c497bae95ec5e794ad05816f8c908e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2893568
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74573}
Various WebAssembly APIs that don't have observable side-effects aren't
marked as such, leading to the inability of DevTools front-end to
generate eager evaluation previews in the Console, and also making them
unusable in conditional breakpoints and logpoints.
Bug: chromium:1164241
Change-Id: I8f0675d2ed5b362b34a6f6c756d372a61e9e8564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891571
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74563}
The WebAssembly specification requires the "name" property of (exported)
function wrappers to hold the index of the function within the module,
and the default ToString algorithm for Function instances thus generates
something along the lines of `function 42() { [native code] }`, which is
technically correct, but not very useful to developers to diagnose
(humans don't think of functions in a module in terms of their indices).
With this CL, we change the description returned for Wasm (exported)
functions to use the debug name of the Wasm function instead.
Screenshot: https://imgur.com/a/FVPeXDU.png
Doc: http://bit.ly/devtools-wasm-entities
Fixed: chromium:1206620
Bug: chromium:1164241
Change-Id: I096abc287ea077556c13c71f8d71f64452ab4831
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891570
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74517}
This changes the names reported in stack traces via the Chrome DevTools
protocol to follow the WAT naming convention for functions. This aligns
the behavior here with the rest of DevTools (i.e. the disassembly in the
Sources panel and the Scope sidebar, as well as the Console REPL) to use
one consistent naming scheme.
Fixed: chromium:1159307
Doc: http://bit.ly/devtools-wasm-entities
Bug: chromium:1162229, chromium:1164241, chromium:1071432
Change-Id: Ibe543f39c775944072073fe5f0959412529aa19b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878734
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74456}
Our current logic for the console API's monitor implementation relies on
JavaScript's arguments array. In arrow functions, this results in an
error, resulting missing print statements from monitor.
This CL at least re-enables the print statements, but does not print the
arguments in the case of arrow functions.
Change-Id: Ibf6c2a0fb5e0cc911c257520a59a875992fe3777
Bug: chromium:1206137
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880216
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74437}
As per WebAssembly Web API[1], the engine should only consider names
from the name section to synthesize function names in the context of
call stacks. We previously also added support to harvest the exports
table here in an attempt to improve the DevTools debugging experience,
but that needs a separate fix specifically for the inspector (which
should also take into account the imports to harvest names).
[1]: https://webassembly.github.io/spec/web-api/index.html#conventions
Fixed: chromium:1164305
Change-Id: I4bde5c8398a5164f1d8ac9060ad3743ed494c41e
Bug: chromium:1159307, chromium:1164241, chromium:1071432
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874464
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74382}
Previously we'd attach source positions to implicit returns that are
generated when leaving an async function with a promise rejection. This
was due to the use of `kNoSourcePosition` on the `end_position` in the
`ReturnStatement` nodes as indicator to pick the return position from
the function literal, instead of really not putting a source position on
that specific `Return` bytecode.
This CL adds a dedicated marker to `ReturnStatement` to express that the
`BytecodeGenerator` should put the return position from the function
literal there instead of overloading the meaning of `kNoSourcePosition`.
Bug: chromium:901819, chromium:782461
Fixed: chromium:1199919, chromium:1201706
Change-Id: I3647e0c3d711e9c3d6ae44606b70ec92ad82e1cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859945
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74301}
The "Restart frame" feature was implemented as part of LiveEdit and
primarily used to support LiveEdit of active functions, but that was
previously disabled as part of https://crrev.com/c/2846892 because it's
too brittle and causes crashes when using seemingly unrelated features.
The "Restart frame" feature was also available as a context menu item
separately in the DevTools front-end, but that was also already removed
as part of https://crrev.com/c/2854681 earlier. So all uses are gone
now.
This change works by marking Debugger.restartFrame as deprecated and
having it respond with a ServerError all the time. It thus allows us to
remove a whole bunch of machinery that was essentially just put in
various places to support the restart_fp_ magic. In particular the
debugger no longer needs any machine specific builtins now.
Bug: chromium:1195927
Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484
Fixed: chromium:1203606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74276}
Previously we'd allow to replace the source of functions that are on the
current execution stack under certain conditions, but this has resulted
in an endless stream of bugs due to weird edge cases, and so we're now
limiting LiveEdit to functions that don't have any activation (including
not a suspended generator / async function activation).
We might eventually add the ability to LiveEdit functions with
activations and have them "upgrade upon next invocation", but that
doesn't seem to be an extremely important use case right now.
Fixed: chromium:1195927
Change-Id: I87a45ba4d0ddcfbf867bd4e73738d76b2d789e04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846892
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74249}
This is a reland of 2b94e5677f
Original change's description:
> [inspector] Report [[Prototype]] as internal property.
>
> Previously the inspector was trying to add a special `__proto__`
> property to every JSObject, which looked and behaved like a real
> data property on the object. But this is confusing to developers
> since `__proto__` is not a real data property, but usually an
> accessor property on the `Object.prototype`.
>
> Additionally all other internal properties are reported using the
> [[Name]] notation, with the [[Prototype]] having been the strange
> outlier.
>
> Drive-by-cleanup: Use an ArrayList to collect the name/value pairs
> inside Runtime::GetInternalProperties(), which makes this function
> more readable and easier to add things.
>
> Bug: chromuium:1162229
> Fixed: chromium:1197019
> Screenshot: https://imgur.com/a/b7TZ32s.png
> Change-Id: Ic4c1e35e2e65f90619fcc12bf3a72806cadb0794
> Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814565
> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73881}
Bug: chromuium:1162229, chromium:1197019
Screenshot: https://imgur.com/a/b7TZ32s.png
Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM
Change-Id: Ie1e2276b385b18a5f865fdae583d1ce0101157c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2820970
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73899}
This reverts commit 2b94e5677f.
Reason for revert: Speculative based on layout test failures on
win and mac which could block the roll:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Win/5294https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Mac/4955
Original change's description:
> [inspector] Report [[Prototype]] as internal property.
>
> Previously the inspector was trying to add a special `__proto__`
> property to every JSObject, which looked and behaved like a real
> data property on the object. But this is confusing to developers
> since `__proto__` is not a real data property, but usually an
> accessor property on the `Object.prototype`.
>
> Additionally all other internal properties are reported using the
> [[Name]] notation, with the [[Prototype]] having been the strange
> outlier.
>
> Drive-by-cleanup: Use an ArrayList to collect the name/value pairs
> inside Runtime::GetInternalProperties(), which makes this function
> more readable and easier to add things.
>
> Bug: chromuium:1162229
> Fixed: chromium:1197019
> Screenshot: https://imgur.com/a/b7TZ32s.png
> Change-Id: Ic4c1e35e2e65f90619fcc12bf3a72806cadb0794
> Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814565
> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73881}
Bug: chromuium:1162229
Change-Id: Ia893ad672eb370fa6fce7eddf2947bf8f6755831
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2818386
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73886}
Previously the inspector was trying to add a special `__proto__`
property to every JSObject, which looked and behaved like a real
data property on the object. But this is confusing to developers
since `__proto__` is not a real data property, but usually an
accessor property on the `Object.prototype`.
Additionally all other internal properties are reported using the
[[Name]] notation, with the [[Prototype]] having been the strange
outlier.
Drive-by-cleanup: Use an ArrayList to collect the name/value pairs
inside Runtime::GetInternalProperties(), which makes this function
more readable and easier to add things.
Bug: chromuium:1162229
Fixed: chromium:1197019
Screenshot: https://imgur.com/a/b7TZ32s.png
Change-Id: Ic4c1e35e2e65f90619fcc12bf3a72806cadb0794
Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814565
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73881}
These tests unnecessarily rely on the `//# sourceURL` annotation. This
is preparatory work to eventually move the treatment of `sourceURL` to
the DevTools front-end.
Bug: chromium:1183990
Change-Id: I934eb1580f503b7b9f8d97c250b7c798bc67e268
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814568
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73878}
This fixes a bug in which CompileTopLevel has a pending exception
that is never taken care of. This CL adds a check for the output
of CompileTopLevel and clears the pending exceptions if existent.
Also-by: bmeurer@chromium.org
Bug: chromium:1190290
Change-Id: Ieba537d5af78fc35475f9547c240c70850bea608
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773346
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73561}
This is a more canonical type name, and is in line with {kVoidCode}.
Change-Id: Iaae9524b6fb6ecaafd63ce81cf30e3d01ca3e525
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2775565
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73557}
The original CL was reverted because PC authentication was missing for
the `caller_pc` in the stack walk. This caused a crash on the CFI bot.
PS1 is the original CL, later patch sets contain the fix.
Original Message:
[wasm] Emit safepoint info for callee-saved registers in the deopt-index
Encode safepoint info of callee-saved registers in the deopt index of
the normal safepoint.
R=clemensb@chromium.org, jkummerow@chromium.org
Change-Id: I633cd715eccc697e888cd381e3bda1a47d0d0851
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759520
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73464}
Add a test for a module without a start function; in that case, we want
to break when first calling into the module (via an exported function).
R=bmeurer@chromium.org
Bug: chromium:1151211
Change-Id: Id14978b5feff4dcd64cff828951f2a00b73c9736
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2763880
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73440}
This reverts commit 74960db4db.
Reason for revert: Segfaults on CFI: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/4999/overview
Original change's description:
> [wasm] Emit safepoint info for callee-saved registers in the deopt-index
>
> Encode safepoint info of callee-saved registers in the deopt index of
> the normal safepoint.
>
> Change-Id: I93bd0d2330b7f592b767860743c04a65ddaa92f5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739977
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73395}
Change-Id: Ic4803b06a64b615f2258c594b601b4e8fd4b7bff
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759513
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73396}
Encode safepoint info of callee-saved registers in the deopt index of
the normal safepoint.
Change-Id: I93bd0d2330b7f592b767860743c04a65ddaa92f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739977
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73395}
This changes the behavior of SetBreakpointForScript to find more
accurate break positions.
Previously, setting a breakpoint would only consider the shared
function info that contained the requested position for setting a
breakpoint. More intuitively, a breakpoint should not necessarily
be set in a function that contains the position, but in the closest
breakable location that comes after the position we requested.
To achieve this we:
1. find the shared function info of the inner most function
that contains the requested_position.
This function's end position is used to find other shared function
infos in step 2.
2. search for all shared function infos that intersect with the
range [requested_position, inner_most_function.break_position[.
3. From the shared function infos extracted in 2, find the one
that has the closest breakable location to requested_position.
Also-By: bmeurer@chromium.org
Fixed: chromium:1137141
Change-Id: I4f4c6c3aac1ebea50cbcad9543b539ab1ded2b05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742198
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73392}
This is the V8 side change for https://crrev.com/c/2744048, which an
explicit "stack" property into the (renamed) "Expression" scope to align
the behavior and appearance of that scope with the other scopes.
Fixed: chromium:1159310
Bug: chromium:1071432, chromium:1159307
Change-Id: Ic070c50b674d8c1cff4a93538f708cc431c3f2cb
Screenshot: https://imgur.com/a/ryFiOGA.png
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748591
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73321}
This fixes a null pointer access in FindSharedFunctionInfo that
was introduced when adding a guard to top level function
compilation.
Bug: chromium:1185540
Change-Id: I24b9752637aba0e660bd8f20be83522e1009b69f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742194
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73258}
This adds support for WasmGC objects (structs/arrays) to the
inspector backend. For prettier printing, it also adds support
for reading the "type" and "field" subsections of the "name"
section in Wasm modules.
This patch includes a revert of most of commit
crrev.com/987a7f4ae45ebfc986525075277debdf73001fc2 because
types are more complicated now.
Bug: v8:7748, chromium:1177784
Change-Id: Icec52cbbb32291b0e773b40be6771a678c6ec79b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715193
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73212}
This adds a re-compilation of top level functions in
getPossibleBreakpoints if no candidates could be found.
This step is necessary as the GC may remove SharedFunctionInfo about
top-level functions.
Bug: chromium:1137141
Change-Id: I8830438d78751ba318d65f43d790ee98f306a57e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696154
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73008}
Eager evaluation in DevTools console relies on the builtins side
effect attribution.
Setters on Date object should be marked as no side effects if called
on the temporary object.
This bug was uncovered after considering screenshot from a tweet [1].
[1] https://twitter.com/shuding_/status/1362132984376160256
Change-Id: Iedc0e29e2bdab719304e2f0a0435845f24eaaadc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2703459
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72835}
In case there's no exact match for the breakable location in
SetBreakpoint(), don't try to find the syntactically closest break
location, but rather find the first possible break location in bytecode
order. In particular when trying to set a breakpoint in a line with
for-of or an array destruction, there's no point in going for the
syntactically closest to the beginning of the line, but rather go for
the semantically first, as the intiution for setting a breakpoint on a
line is that the debugger stops before it executes anything on said
line. In the example
```
var [^a, ^b] = ^func();
```
there are three possible break locations, and the correct one is the
last one as the call to func will happen first at runtime.
For generators that's currently broken because of the implicit initial
yield, and same with modules (see crbug.com/901819), so we keep the
previous behavior of finding the closest breakable location, and will
fix that independently in a follow up CL.
Bug: chromium:901819
Fixed: chromium:782461
Also-By: yangguo@chromium.org
Change-Id: Ie724c5cb08e5f4edd90a450d99e001dff06bbe7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696586
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72813}
