Commit Graph

1206 Commits

Author SHA1 Message Date
Nikolaos Papaspyrou
9554743a0b [heap] Refactor the stack object
The stack object is primarily used for conservative stack scanning, both
by the V8 and C++ garbage collectors. This CL introduces the notion of a
"stack context", which comprises of the current stack marker (the lowest
address on the stack that may contain interesting pointers) and the
values of the saved registers. It simplifies the way in which iteration
through the stack is invoked: the context must have previously been
saved and iteration always uses the stack marker.

Bug: v8:13257
Bug: v8:13493
Change-Id: Ia99ef702eb6ac67a3bcd006f0edf5e57d9975ab2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4017512
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84303}
2022-11-16 16:21:50 +00:00
Clemens Backes
abd024b5f3 [wasm] Rename a testing flag
Rename the '--wasm-max-code-space' flag to
'--wasm-max-committed-code-mb'. We will introduce a new flag to set the
maximum size of a wasm code space, so the old name would be misleadingly
close to the new flag.

R=jkummerow@chromium.org

Bug: v8:13436
Change-Id: I7a86300e4f25858add1a62f9989189035ea855ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022709
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84242}
2022-11-14 14:01:13 +00:00
Manos Koukoutos
01aa7f4ad6 Reland "[wasm-gc] Canonicalize JS Numbers as i31ref at the boundary"
This is a reland of commit 936b61a209

Change compared to original: Fix parameter types for CallRuntimeStub
in Liftoff.

Original change's description:
> [wasm-gc] Canonicalize JS Numbers as i31ref at the boundary
>
> JS numbers flowing into Wasm as i31ref should be canonicalized at the
> boundary. In-range numbers get canonicalized to Smis, and out-of-range
> numbers to HeapNumbers. This way, casting to i31ref, or checking for
> i31ref when casting to other types, is reduced to a Smi check.
>
> Bug: v8:7748
> Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84219}

Bug: v8:7748
Change-Id: I67737150252b844a296338db0c60f76b470aa43b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022711
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84240}
2022-11-14 13:36:18 +00:00
Dominik Inführ
b9eeaf1b88 Reland: [heap] Load MarkingBarrier from thread local on main thread
Reland of https://crrev.com/c/3998633.

Each thread has its own MarkingBarrier instance for incremental
marking. A thread local variable is used to get the current thread's
instance on background threads.

However on main threads this thread local variable was always
set to nullptr. The main thread would get to its own instance through
the heap_ field in the host object's page header. This was solved this
way because setting current_marking_barrier on the main thread
seemed quite complex. Multiple isolates may be run on the same thread
and isolates may even be migrated between threads.

However, with --shared-space loading the heap_ field for a shared
object would return the main isolate's heap and we end up with
the wrong MarkingBarrier instance on client isolates. So this
CL makes main and background threads more uniform by setting the
thread local field also on the main thread. The field is set by
the already existing v8::Isolate::Scope API. Some embedders might have
to add these scopes if they don't use them properly already.

Bug: v8:13267
Change-Id: Idc257ecf6b6af09a379bdd7cd7c1d4a5e46689c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4016715
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84237}
2022-11-14 12:18:18 +00:00
Nico Hartmann
85b4c7bf87 Revert "[wasm-gc] Canonicalize JS Numbers as i31ref at the boundary"
This reverts commit 936b61a209.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20no%20pointer%20compression/2000/overview

Original change's description:
> [wasm-gc] Canonicalize JS Numbers as i31ref at the boundary
>
> JS numbers flowing into Wasm as i31ref should be canonicalized at the
> boundary. In-range numbers get canonicalized to Smis, and out-of-range
> numbers to HeapNumbers. This way, casting to i31ref, or checking for
> i31ref when casting to other types, is reduced to a Smi check.
>
> Bug: v8:7748
> Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84219}

Bug: v8:7748
Change-Id: Ia74e49147d230f9217ebeb2bf435d10d8f93126e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020457
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84221}
2022-11-11 16:05:32 +00:00
Manos Koukoutos
936b61a209 [wasm-gc] Canonicalize JS Numbers as i31ref at the boundary
JS numbers flowing into Wasm as i31ref should be canonicalized at the
boundary. In-range numbers get canonicalized to Smis, and out-of-range
numbers to HeapNumbers. This way, casting to i31ref, or checking for
i31ref when casting to other types, is reduced to a Smi check.

Bug: v8:7748
Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84219}
2022-11-11 15:13:10 +00:00
Matthias Liedtke
40a156813e [testing][wasm] Inspector: Print 'null' for empty table entries
The wrapper obects for the debugger displayed e.g. in dev tools
contain a proper `null` value already.

Note: This only affects the printing of wasm tables in the test.
Change-Id: I3c2e9580b0a3983b66b9c3e2e16e5a2b322a9ff7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020261
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84201}
2022-11-11 10:53:52 +00:00
Andrey Kosyakov
7d2b1f5368 Fix gcc build following https://crrev.com/c/v8/v8/+/3976353
Use USE(), (void) is void with GCC.

Bug: chromium:1352175
Change-Id: Ic254a5d0ca2bb6d8179dfe5ba74f1d0753d456ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022027
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84193}
2022-11-10 22:35:41 +00:00
Andrey Kosyakov
aa684004d0 DevTools: use a barrier to sync runIfWaitingForDebugger from multiple sessions
This introduces a barrier that ensures that
`V8InspectorClient::runIfWaitingForDebugger()` is only invoked once all
sessions that requested a paused have invoked runIfWaitingForDebugger.

Downstream change: https://chromium-review.googlesource.com/c/chromium/src/+/3977348

Bug: chromium:1352175
Change-Id: I9049c2de6da8e690ad4312cd6cb799619125bb62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976353
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84191}
2022-11-10 20:23:01 +00:00
Nico Hartmann
617d4ed8e9 Revert "[heap] Load MarkingBarrier from thread local on main thread"
This reverts commit 910def9edc.

Reason for revert: Speculative Revert https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/9800/overview

Original change's description:
> [heap] Load MarkingBarrier from thread local on main thread
>
> Each thread has its own MarkingBarrier instance for incremental
> marking. A thread local variable is used to get the current thread's
> instance on background threads.
>
> However on main threads this thread local variable was always
> set to nullptr. The main thread would get to its own instance through
> the heap_ field in the host object's page header. This was solved this
> way because setting current_marking_barrier on the main thread
> seemed quite complex. Multiple isolates may be run on the same thread
> and isolates may even be migrated between threads.
>
> However, with --shared-space loading the heap_ field for a shared
> object would return the main isolate's heap and we end up with
> the wrong MarkingBarrier instance on client isolates. So this
> CL makes main and background threads more uniform by setting the
> thread local field also on the main thread. The field is set by
> the already existing v8::Isolate::Scope API. Some embedders might have
> to add these scopes if they don't use them properly already.
>
> Bug: v8:13267
> Change-Id: Idfdaf35073d04dd5e13ad6065ef42eae3ce6a259
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3998633
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84144}

Bug: v8:13267
Change-Id: Id8493dfac03d789721ca30cd29b0dd4b67006881
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4017192
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84151}
2022-11-09 15:13:44 +00:00
Dominik Inführ
910def9edc [heap] Load MarkingBarrier from thread local on main thread
Each thread has its own MarkingBarrier instance for incremental
marking. A thread local variable is used to get the current thread's
instance on background threads.

However on main threads this thread local variable was always
set to nullptr. The main thread would get to its own instance through
the heap_ field in the host object's page header. This was solved this
way because setting current_marking_barrier on the main thread
seemed quite complex. Multiple isolates may be run on the same thread
and isolates may even be migrated between threads.

However, with --shared-space loading the heap_ field for a shared
object would return the main isolate's heap and we end up with
the wrong MarkingBarrier instance on client isolates. So this
CL makes main and background threads more uniform by setting the
thread local field also on the main thread. The field is set by
the already existing v8::Isolate::Scope API. Some embedders might have
to add these scopes if they don't use them properly already.

Bug: v8:13267
Change-Id: Idfdaf35073d04dd5e13ad6065ef42eae3ce6a259
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3998633
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84144}
2022-11-09 12:10:24 +00:00
Simon Zünd
b278b806f1 [inspector] Add regression test for hoisting and debug-evaluate
This CL adds a regression test for sloppy block function hoisting and
debug-evaluate. This was fixed in the past but the test was missing.

Fixed: chromium:1246897
Change-Id: I1d7dcbd4d95ef8e5a09f09615de017b65c3e7087
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4011039
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84141}
2022-11-09 11:09:18 +00:00
Jaroslav Sevcik
283fb5f06f [inspector] Trigger requested pause after instrumentation pause
If a CDP client requests Debugger.pause during instrumentation pause,
the requests is currently ignored.

With this patch, the debugger will take note of a pause request during
instrumentation pause and enter the pause once the instrumentation pause
resumes.

Bug: chromium:1381967
Change-Id: I4d0337a92fa31d0666ab02b54f95aba4d89592b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008379
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84138}
2022-11-09 09:42:37 +00:00
Benedikt Meurer
97924c16ff [inspector] Allow to break only on caught exceptions.
This introduces a new "caught" case for Debugger.setPauseOnExceptions,
which instructs the V8 Debugger to only break on exceptions that are
predicted as caught. Previously it wasn't possible to express this with
Chrome DevTools Protocol.

Bug: chromium:1324920, chromium:1346231
Change-Id: I507cfb6058148b2e238b8f66e9720ab68cb81575
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013330
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84137}
2022-11-09 07:44:28 +00:00
Simon Zünd
e24c3ac022 [inspector] Add regression test for leaking vars in debug-evaluate
This CL adds the regression test originally authored for
crbug.com/1085693. It no longer crashes or re-produces but we were
unable to bisect to the CL that fixed the problem since bisecting
seems to be broken.

R=bmeurer@chromium.org

Fixed: chromium:1085693
Change-Id: Iaaf2b557767a02829fc497591ed7f3623965a66c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4012718
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84108}
2022-11-08 08:08:37 +00:00
Shu-yu Guo
cd31c5bdcc [debug] Fix locals blocklist reuse outside of closures
Bug: chromium:1363561
Change-Id: I50c1448d79cc64f7de456f20941de0add8c464c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4004801
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84072}
2022-11-04 22:05:00 +00:00
Simon Zünd
8ab1c88c01 [debug] Add 'new.target' to the materialized stack locals for evaluate
This CL adds "new.target" to the ScopeObject with the materialized
stack local variables. It's only available if the parser actually
allocates a variable for it, otherwise we currently throw a
ReferenceError.

The added test also ensures that "new.target" is only included for
debug-evaluate, but NOT for the scope view. Having ".new.target"
show up there would be more confusing than helpful.

Drive-by: Remove bogus DCHECK. The context we try to lookup
"new.target" can be anything, not just a `with` context.

R=bmeurer@chromium.org, leszeks@chromium.org

Bug: chromium:1246863
Change-Id: Id4f99b3336044904e3dc76912f65b6f63f092258
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4003039
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84069}
2022-11-04 16:03:16 +00:00
Simon Zünd
5d0b8b0ff1 [debugger] Throw exception if 'var x' fails in debug eval in module
This is an extension to the fix landed in https://crrev.com/c/3295348.

We should also throw the exception when we are paused in a module.
This is a constellation that can only happen with debug-evaluate as
'eval's in modules are always indirect, whereas debug-evaluate uses
direct, sloppy eval.

R=bmeurer@chromium.org, leszeks@chromium.org

Bug: chromium:1352303
Change-Id: I7373462dc6ae419e0a1a05a385ab81f204ff03ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976510
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83917}
2022-10-26 05:39:32 +00:00
Simon Zünd
f44d43de74 [inspector] Land regression test that now succeeds
With the blocklist re-use experiment we now handle locals near the
script/global scope correctly.

This CL lands the regression test of @bmeurer since it passes now.

R=bmeurer@chromium.org

Fixed: chromium:1209117
Change-Id: I2cb0ec1689b4fd32501886cc8bdd49486beef4dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976513
Commit-Queue: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83903}
2022-10-25 12:53:04 +00:00
Benedikt Meurer
b2892b5f24 [inspector] Add [[WeakRefTarget]] internal property.
This adds a new [[WeakRefTarget]] internal property to
`Runtime.getProperties` results for `JSWeakRef` results
(also included in the preview), which will be used by
DevTools to show the target of the weak reference without
having to explicitly call `deref()` on them. As part of
this we also have (temporary) strong references to the
target, slightly changing behavior, but that's consistent
with how DevTools deals with `JSWeakMap` and `JSWeakSet`.

Bug: chromium:1267690
Change-Id: I2a9ef9261996fcdee20fbd0fc728d11208c82459
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3970598
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83844}
2022-10-21 12:14:52 +00:00
Dave Tapuska
2f0384871f [execution] Pass microtask queue from Context to MicrotasksScope
With a unique microtask queue possibly per context we need to pass
the microtask queue for the MicrotasksScope otherwise the default one
for the isolate will be used.

BUG=chromium:961186

Change-Id: Ib085f08e20185c69760aeea335d673d9c4c72999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3950216
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83803}
2022-10-19 14:56:37 +00:00
Clemens Backes
e69505242f [wasm] Add more output to console-profile-wasm test
The test occasionally times out, and it's unclear why.
This CL adds an explicit timeout to the test (30 seconds), and prints
all seen profiles after that. This makes it easier to see which frame is
missing from the profiles.

As a drive-by refactoring, we now also use
{InspectorTest.runAsyncTestSuite} instead of the hand-written sequential
execution of the asynchronous test functions.

R=thibaudm@chromium.org

Bug: v8:13370
Change-Id: I67f53a819706c8e5971bf32dc925d90b21c96243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3956976
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83748}
2022-10-17 15:18:25 +00:00
Clemens Backes
444e6e3482 Reland "[flags] Remove FLAG_* aliases"
This is a reland of commit e3096c31d6.
The one additional use of FLAG_turboshaft is also rewritten now.

Original change's description:
> [flags] Remove FLAG_* aliases
>
> This removes the deprecated FLAG_* aliases, and switches remaining uses
> to the new v8_flags syntax.
>
> R=jkummerow@chromium.org
>
> Bug: v8:12887
> Change-Id: Icde494a3819a9b1386c91e44f5d72a55666d9eae
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952350
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83686}

Bug: v8:12887
Change-Id: I978df89f51e11c9a101ff3c1e385b1eced697a74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3953292
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83717}
2022-10-14 13:13:55 +00:00
Simon Zünd
104c564460 [liveedit] Fix DCHECK when changing outer scope variables
This CL fixes the ScopeInfo::Equals DCHECK when we update "unchanged"
functions. We don't need to make sure the outer scope info matches
exactly. LiveEdit already makes sure that outer scope infos don't
change in a way that would be bad for "unchanged" functions. It's
fine if they only change subtly by e.g. moving a outer context variable from `let` to `const`.

Note that we don't touch existing closures on the heap, those
will still reference the old scope info.

R=jarin@chromium.org

Bug: chromium:1363561
Change-Id: I5117d345d1f70e08ea436ed89f2c6deaff3f0538
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3953496
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83713}
2022-10-14 11:35:15 +00:00
Clemens Backes
54543299e5 Revert "[flags] Remove FLAG_* aliases"
This reverts commit e3096c31d6.

Reason for revert: In-flight collision (new usage of FLAG_turboshaft): https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Android%20Arm%20-%20builder/48026/overview

Original change's description:
> [flags] Remove FLAG_* aliases
>
> This removes the deprecated FLAG_* aliases, and switches remaining uses
> to the new v8_flags syntax.
>
> R=​jkummerow@chromium.org
>
> Bug: v8:12887
> Change-Id: Icde494a3819a9b1386c91e44f5d72a55666d9eae
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952350
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83686}

Bug: v8:12887
Change-Id: I7688143bde2c5890842fc6362e3f569f172f68b0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952594
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83689}
2022-10-13 14:09:58 +00:00
Clemens Backes
e3096c31d6 [flags] Remove FLAG_* aliases
This removes the deprecated FLAG_* aliases, and switches remaining uses
to the new v8_flags syntax.

R=jkummerow@chromium.org

Bug: v8:12887
Change-Id: Icde494a3819a9b1386c91e44f5d72a55666d9eae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952350
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83686}
2022-10-13 14:01:32 +00:00
Benedikt Meurer
ade6d191c8 [debug] Treat Comma-separated Expressions like Statements when Stepping.
This CL introduces statement positions before the right-hand side of
comma expressions, in order to align the stepping behavior (and also
generally the breakpoint behavior) around semicolon (;) and comma (,)
separated expressions.

The motivation here is that left-hand sides of comma expressions are
evaluated purely for their side-effects and as such, they aren't
really any different from statements from a developers perspective.
And more importantly, minifiers (like UglifyJS, terser, or esbuild)
by default turn statement expression lists into comma-separated
expressions, thus implicitly changing the stepping behavior in ways
that are difficult to understand for developers.

Doc: http://go/chrome-devtools:comma-stepping-proposal
Demo: https://devtools-dbg-stories.netlify.app/crbug-1370200.html
Video: https://i.imgur.com/5WC03wF.gif
Fixed: chromium:1370200
Change-Id: I38f288d964bc992d1de0dce2ed2becd4220793df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3934288
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83599}
2022-10-10 13:14:57 +00:00
Marja Hölttä
283791d250 [inspector] Remove Type Profiler
See https://docs.google.com/document/d/1dJHFRXKE4NUchvYweuyzsolXDEWACr-jJZEPyC6f9EQ/edit?usp=sharing

Change-Id: Ie5b30db30d55ba701a336d8a59dbff7771276e96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3936281
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83593}
2022-10-10 11:50:16 +00:00
Simon Zünd
ad884d036f [inspector] Don't use v8::Promise::Resolver for REPL mode
REPL mode always returns a promise since we basically turn the
evaluated script in an async function. More-over, we stash the result
as a property on a plain JS object. This prevents promise chains to
resolve too far if the result of the evaluation is a promise itself.

Long story short, we don't need to wrap REPL mode results in
`Promise.resolve`, but can add the then/catch handlers directly.

This fixes the DevTools console when working with broken promise
polyfills or broken thenables.

R=bmeurer@chromium.org

Fixed: chromium:1371072
Change-Id: I96aa8eaf5939fdf6231712b047b50fee734efc0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3929037
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83578}
2022-10-07 19:38:13 +00:00
Simon Zünd
45026a66ef [liveedit] Replace ScopeObject instead of updating positions in-place
Currently, LiveEdit updates the source positions of unchanged SFIs
in-place (the SFI could have moved due to other functions changing).

This interfere with our plans to re-use ScopeInfo-based blocklists
for debug-evaluate. Entries in the global block list cache are keyed
by ScopeInfo's source position. Any closure that escaped a
debug-evaluate will point to the old ScopeInfo in its context chain
and the block lists should stay in-place in case the escaped closure
is called again.

Rather than updating ScopeInfos in-place, this CL updates the
ScopeInfo object wholesale for unchanged SFIs. This is safe todo
given that the old and new ScopeInfo are identical modulo source
positions.

Drive-by: Take the source position of the function token from the
`FunctionLiteral` rather than doing a more expensive position
translation.

Bug: chromium:1363561
Change-Id: I2b8476edd8d7dc4c618e53551aa5692a21d6fb32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3932724
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83536}
2022-10-05 13:14:47 +00:00
Shu-yu Guo
3dd9576ce3 [inspector] Support Symbols in EntryPreview
The Symbols-as-WeakMap-keys proposal allows non-Symbol.for Symbol values
in weak collections, which means it can show in EntryPreviews.

Also apparently Symbols in regular Maps and Sets were also unsupported.

Bug: v8:13350, v8:12947
Change-Id: Ib10476fa2f3c7f59af67933f0bf61640be1bbd97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3930037
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83518}
2022-10-04 15:33:11 +00:00
Simon Zünd
699147d17f [inspector] Fix user-after-free bug around async evaluations
This CL fixes a use-after-free bug where we try to access an
`InjectedScript` object after it died. This can happen when we
transition into JS and back and the context group dies in the mean
time (e.g. because of a navigation). Normally we check for this but
we missed a call to `Promise#then`.

The access that triggers the UaF is when we try to stash away the
protocol callback function after returning from `Promise#then`.
The callback function is responsible for sending the protocol
response back to DevTools containing the result of the evaluation.

There are two objects with different lifetimes involved:

  - InjectedScript: Owns the `EvaluationCallback`. We keep a
    a reference in case the context group dies. This allows us to
    cancel any pending evaluate requests.

  - ProtocolPromiseHandler: Has a reference to `EvaluationCallback`.
    The handler itself is managed by the V8 GC via `v8::External`
    and a weak `v8::Global`.

When the `ProtocolPromiseHandler` wants use the callback to send
a response, it needs to take ownership first.

We could invert the ownership but it's preferable for evaluation
callbacks to die together with execution contexts and not when the
GC feels like it.

We fix the UaF by using an `InjectedSript::ContextScope` and reloading
the `InjectedScript` after we return from `Promise#then`. Then
we can take proper ownership of the callback and use it in case the
call failed.

R=jarin@chormium.org

Fixed: chromium:1366843
Change-Id: I3a68e8609a9681d7343c71f43cc6e67064f41530
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925937
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83506}
2022-10-04 06:21:23 +00:00
Benedikt Meurer
d8990fdc76 [debug] Remove statement position from spreads in array literals.
Following up on https://crrev.com/c/3916453, we also remove the
confusing breakable and steppable positions from spreads in array
literals. These positions provide no meaningful advdantage for
developers, but just makes it annoying to step through code that
contains spreads.

Drive-by: Add similar inspector tests to ensure that the positions in
the stack are correctly inferred when stopped in the Symbol.iterator or
the next methods.

Before: https://imgur.com/jVf2JeB.png
After: https://imgur.com/u8SfNhy.png
Fixed: chromium:1368971
Change-Id: Ibf791167936c1ed28ac3240acb7c0846b11ebecb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925200
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83469}
2022-09-28 10:51:34 +00:00
jameslahm
031b98b25c [runtime] Clear array join stack when throwing uncatchable
... exception.

Array#join depends array_join_stack to avoid infinite loop
and ensures symmetric pushes/pops through catch blocks to
correctly maintain the elements in the join stack.
However, the stack does not pop the elements and leaves in
an invalid state when throwing the uncatchable termination
exception. And the invalid join stack state will affect
subsequent Array#join calls. Because all the terminate
exception will be handled by Isolate::UnwindAndFindHandler,
we could clear the array join stack when unwinding the terminate
exception.

Bug: v8:13259
Change-Id: I23823e823c5fe0b089528c5cf654864cea78ebeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3878451
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#83465}
2022-09-28 07:40:55 +00:00
Benedikt Meurer
c45a214cb5 [debug] Remove confusing destructuring statement positions.
This change removes the confusing statement positions that were
previously emitted for every binding identifier within both array
and object destructurings. These statement positions were reported as
breakable positions to the debugger front-end, and during stepping, the
debugger would also stop on them. This is confusing and very different
from how other expressions work (we don't emit statement positions
within expressions normally).

Instead we emit expression positions for the binding identifiers, which
are used to construct the source positions for stack traces. As a drive
by we also add the missing position (and test cases) for sub-patterns.

In particular this aligns the stepping and breakpoint behavior around
destructuring expressions with that of Firefox DevTools.

We also remove the original test cases, introduced with
https://codereview.chromium.org/1542813003 and
https://codereview.chromium.org/1533313002, which were written as
debugger tests, with new inspector tests that also ensure that the
call positions are correct.

Fixed: chromium:1368444
Bug: v8:811
Doc: http://go/chrome-devtools:destructuring-breakpoints-design
Change-Id: I4d53ad059b5eede73abd01d9bc9fdf8263c55c9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916453
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83455}
2022-09-27 14:19:24 +00:00
Omer Katz
f30336074f [heap] Fix tests for single generation
Bug: v8:13322
Change-Id: I0826175aeb47c07a7b53792d4c271a095b44e322
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3915225
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83413}
2022-09-25 17:05:57 +00:00
Benedikt Meurer
4739535d71 [debug] Remove breakable location right before suspending.
This aligns the breakpoint behavior of YieldExpression and
AwaitExpression with the behavior of AssignmentExpression
in V8. It basically boils down to not reporting expression
positions on SuspendGenerator bytecodes as breakable
locations.

In particular the initial implicit yield of any generator
function is no longer a breakable position. In light of
this changes we also refine https://crrev.com/c/2949099
to not be able to step to the initial implicit yield
either, which would otherwise be really odd.

Before: https://imgur.com/KYy9F1S.png
After: https://imgur.com/gCnWU8J.png
Doc: https://goo.gle/devtools-reliable-await-breakpoints
Bug: chromium:901814, chromium:1319019, chromium:1246869
Fixed: chromium:1319019, chromium:1357501
Change-Id: I0c5f83e279918eb392d8f77a8a04c4c0285f938e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3909688
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83392}
2022-09-23 08:28:05 +00:00
Matthias Liedtke
3665fbaaf5 [wasm] Fix inspection of imported wasm tables created in JS
Fixed: chromium:1365101
Change-Id: Ie6f5fa08416348e827de9a389af5d63eba118ceb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3909810
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83385}
2022-09-22 12:01:44 +00:00
Simon Zünd
735401e1fb [inspector] Disable [[Scopes]] internal property
We don't remove the code just yet in case we need to re-enable the
feature. This could be in case we discover workflows not covered by
the "Scope View" and the scopes we report on "Debugger.paused".

R=kimanh@chromium.org

Bug: chromium:1365858
Change-Id: I636cc861af932156944a3f6e0a149cce0f939329
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3905185
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83379}
2022-09-22 07:12:24 +00:00
Seth Brenith
e7f0f26f5e Don't run sampling-heap-profiler-flags with stress-incremental-marking
This test observes GC behavior and needs the garbage collector to work
in a somewhat predictable way.

Bug: v8:13286
Change-Id: I24e6a4f33a644b5f1845cd34558da03fc196f7e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3898721
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83218}
2022-09-15 12:53:28 +00:00
Seth Brenith
3d59a3c2c1 Add option to report discarded allocations in sampling heap profiler
A couple of customers have asked about using devtools to get information
about temporary allocations, with the goal of reducing GC time and/or
peak memory usage. Currently, the sampling heap profiler reports only
objects which are still alive at the end of the profiling session. In
this change, I propose adding configuration options when starting the
sampling heap profiler so that it can optionally include information
about objects which were discarded by the GC before the end of the
profiling session. A user could run the sampling heap profiler in
several different modes depending on their goals:

1. To find memory leaks or determine which functions contribute most to
   steady-state memory consumption, the current default mode is best.
2. To find functions which cause large temporary memory spikes or large
   GC pauses, the user can request data about both live objects and
   those collected by major GC.
3. To tune for minimal GC activity in latency-sensitive applications
   like real-time audio processing, the user can request data about
   every allocation, including objects collected by major or minor GC.
4. I'm not sure why anybody would want data about objects collected by
   minor GC and not objects collected by major GC, but it's also a valid
   flags combination.

Change-Id: If55d5965a1de04fed3ae640a02ca369723f64fdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3868522
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#83202}
2022-09-14 17:39:12 +00:00
Jakob Linke
6904a8120b [cleanup] Remove --stress-opt remnants
.. mostly mentions in mjsunit `Flags:` lines and in comments.

Bug: v8:10386
Change-Id: If79dfdc448d0a3f19883ef1f816e77e750cb4061
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3865964
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82852}
2022-08-31 08:37:44 +00:00
Matthias Liedtke
ee9b0f9f02 [wasm-gc] Debugger: Provide type info for structs and arrays in tables
This change also modifies the way references are typed: Instead of
using the static type (which may be a generic type like anyref) the
actual type based on the referenced object is used.
While this is very useful for arrays and structs (and somewhat nice for
i31 not just being a number but also having some type information), it
means for non-null values that the reference type is "not nullable",
so it will show e.g. "ref $type0" although the static type  might be
"ref null $type0".

Bug: v8:7748
Change-Id: I00c3258b0da6f89ec5efffd2a963889b1f341c3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3852485
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82753}
2022-08-26 14:51:20 +00:00
Matthias Liedtke
8600d58092 [wasm-gc] Rename array.new_fixed_static -> array.new_fixed
This is a left-over of the removal of the dynamic (rtt-based)
variants.

Bug: v8:7748
Change-Id: I93bb74a72543a5697f1102d283c7d65c6be99466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3856577
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82746}
2022-08-26 13:11:38 +00:00
Matthias Liedtke
6a6f5de1a7 [wasm-gc][debugger] Fix struct_index retrieval for generic references
The StructProxy::Create() used the static type information to inspect
the value. However, for abstract references like anyref, dataref, ...
this does not contain the required struct_index.
To fix this the WasmTypeInfo stores the type_index for structs and
arrays.

Bug: v8:7748
Change-Id: I6e1af054711ada5e12c08949c125007e8185e486
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3850296
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82691}
2022-08-24 13:25:50 +00:00
Simon Zünd
85561d6616 [debug] Only apply TDZ 'value unavailable' logic for let/const
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}
2022-08-23 07:19:34 +00:00
Jakob Kummerow
564c0978f4 [stringrefs] Support stringrefs in DevTools inspection
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}
2022-08-17 19:12:09 +00:00
Simon Zünd
fb8bda3a85 [inspector] Fix crash when building preview with a proxy prototype
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}
2022-08-16 13:19:33 +00:00
Simon Zünd
e417b339ee [debug] Report variables in TDZ as 'value unavailable'
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}
2022-08-16 09:59:57 +00:00
Simon Zünd
6a8b90c303 [debug] Fix source position around class literals
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}
2022-08-16 07:16:47 +00:00