This CL introduces a dedicated API to retrieve the current (w.r.t. the
JS stack) script name or sourceURL. Currently, API clients will
collect multiple stack traces in increasing sizes to accomplish the
same goal. The new method walks the JS stack in the same way as the
stack trace collection mechanic but doesn't create/allocate stack info
or callsite objects along the way.
R=bmeurer@chromium.org, yangguo@chromium.org
Doc: https://bit.ly/v8-current-script-name
Bug: chromium:1286677
Change-Id: Id53e4f04bf17349d34f3d581bc712b1f4aa055db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3382818
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78645}
Now that concurrent inlining is shipping on stable, remove support
--no-concurrent-inlining.
Note that it's still possible to run Turbofan exclusively on the
main thread by passing --no-concurrent-recompilation.
Bug: v8:7790, v8:12142, chromium:1240585
Change-Id: I1943bbbcad7dea7e3a3c337c239f14f7d96c23cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308798
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78644}
The receiver is included unconditionally on all platforms
(kJSArgcIncludesReceiver is always true).
Remove all usages of kJSArgcIncludesReceiver from the code.
Bug: v8:11112
Change-Id: I7d62e6de65b73fe6d8c3293f32b500b760b08a3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322980
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78642}
This is a reland of 142dd775b4
Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}
Bug: chromium:1285706
Change-Id: I024e50fc0757fbcd13cb9ffde027dff55f99d25c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386600
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78631}
- Add suspend asm builtin stub, and call it from the suspending
wasm-to-js wrapper
- Rename frame type to match both builtins (prompt and suspend)
- Add suspend bool to the import cache key
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: Ie5a8ca7cbe4bcb91697e05b6470e3d632d608993
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345004
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78628}
Since ManualGCScope changes marking flags it should finalize any
ongoing GC before changing the flags. Otherwise, the GC may observe
inconsistent state.
Bug: chromium:1285706
Change-Id: Ie8ef6a1117ba0523d0bed0c46d9116ffbc02069c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386607
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78618}
This reverts commit 142dd775b4.
Reason for revert: TSAN breaks: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6113/overview
Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}
Bug: chromium:1285706
Change-Id: If1976c0356f450fc068aa4dcc39fb9a0d5417a40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386598
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@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/main@{#78605}
https://crrev.com/c/3293410 added concurrent processing of C++ objects
found through V8 embedder fields. The CL missed that those embedder
fields are not read atomically from JS objects. The problem is that
embedder fields are only aligned to kTaggedSize on builds with pointer
compression and are as such mis-aligned for atomic ops. This is not a
problem for on-heap values as the upper 32bits are anyways computed
from the cage. Is is a problem for generic C++ values though, as they
are used with Oilpan.
This CL adds the standard marker snapshot protocol for embedder fields.
Marker:
1. Snapshot embedder fields
2. Try to mark host object
3. On success: process snapshot
Main thread:
1. On setting embedder fields mark the object black first
2. Emit a write barrier for the embedder fields
This will get simpler with the heap sandbox that uses a separate table
for embedder fields. Once the sandbox is the default configuration, we
can use it as dependency for the concurrent fast path.
Bug: chromium:1285706
Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78604}
This CL fixes 2 issues with string internalization when the string table
is shared:
1. In-place migration of a string's map to Internalized was done before
it was sure that the string is going to be internalized (outside the
critical section). To fix this problem StringTableKey::AsHandle() is
now split into StringTableKey::PrepareForInsertion(), which is
invoked outside the critical section and creates a copy if
necessary, and StringTableKey::GetHandleForInsertion(), which is
invoked inside the critical section only for string table misses.
Migration of the map is handled by this method.
2. TryStringToIndexOrLookupExisting() didn't handle already internalized
strings. So far this was impossible, as this method was only invoked
for strings that were checked not to be internalized. However with
a shared string table, the string could be internalized after the
checks.
Bug: v8:12007
Change-Id: I193d6b54dc41360eee47d21cbcaa36d2652d85dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368103
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78600}
This unifies and simplifies the way we instrument async functions for
the purpose of async stack traces and async stepping. It does so while
retaining the observable behavior on the inspector level (for now).
Previously we'd mark the implicit promise of the async function object
with the async task ID, and whenever we awaited, we'd copy the async
task ID to the throwaway promise that is created by the `await`. This
however made things unnecessarily interesting in the following regards:
1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the
`AsyncFunctionFinished` events, coming from the throwaway promises,
while the implicit promise is "done". This is especially confusing
with rejection propagation and requires very complex stepping logic
for async functions (after this CL it'll be possible to unify and
simplify the stepping logic).
2. We have to thread through the "can suspend" information from the
Parser all the way through AsyncFunctionReject/AsyncFunctionResolve
to the async function instrumentation to decide whether to cancel the
pending task when the async function finishes.
This CL changes the instrumentation to only happen (non recurringly) for
the throwaway promises allocated upon `await`. This solves both problems
mentioned above, and works because upon the first `await` the stack
captured for the throwaway promise will include the synchronous part as
expected, while upon later `await`s the synchronous part will be empty
and the asynchronous part will be the stack captured for the previous
throwaway promise (and the V8Debugger automatically short circuits
stacks with empty synchronous part).
Bug: chromium:1280519, chromium:1277451, chromium:1246867
Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78599}
CompleteInobjectSlackTracking potentially shrinks multiple maps, and
the relation between these maps should be preserved in a concurrent
environment. Thus it is not enough to make each modification
atomically, but all related map modifications must be within a
critical section.
We do this by locking the map_updater_access mutex
CompleteInobjectSlackTracking, and hence moving the function to the
MapUpdater class.
Bug: chromium:1274445,v8:7990
Change-Id: If99bb8b55e03180128ee397d845fa4c269c4241e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379819
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78597}
CDP has a "ExceptionDetails" structure that is attached to various
CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate".
The stack trace in the "ExceptionDetails" structure is used in
various places in DevTools. The information in the "ExceptionDetails"
structure is extracted from a v8::Message object. Message objects
are normally created at the exception throw site and may augment
the error with manually inspecting the stack (both to capture a fresh
stack trace in some cases, as well as to calculate location info).
The problem is that in some cases we want to get an "ExceptionDetails"
structure after the fact, e.g. when logging a JS "Error" object in
a catch block. This means we can't reuse Isolate::CreateMessage as
the JS stack at call time is unrelated to the time when an Error
object was thrown.
To re-use some of the code, this CL introduces a new
"CreateMessageFromException" method that is only available from the
debugging interface (not public V8 API!). The new method works
similar to Isolate::CreateMessage, but:
1) Does not look at the current JS stack, neither for a fresh
stack trace nor for location information.
2) Only uses the "detailed" stack trace for location info.
This is because the "simple" stack trace could have already
been serialized by accessing Error#stack.
Bug: chromium:1278650
Doc: https://bit.ly/runtime-get-exception-details
Change-Id: I0144516001c71786b9f76ae4dec4442fa1468c5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337257
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78586}
This CL doesn't change behavior, only refactors MemoryAllocator:
* De-templatify class, MemoryAllocator is used on slow path and doesn't
really need templates for performance.
* Rename FreeMode names
* Move methods into private section of class
Change-Id: I7894fba956dcd7aa78ad0284d0924662fef4acae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379812
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78580}
We introduce {ConstantExpression}, which represents the most frequent
constant expression types directly, and falls back to a {WireBytesRef}
for the rest. During module decoding, we decode the most common
expressions separately and store them as {ConstantExpression}, so we do
not have to decode them again during module instantiation.
Bug: chromium:1284557
Change-Id: Ie411bbe9811d0d9f6e750ba202bb0ccff801dfee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378347
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78576}
This is a temporary solution so prototyping of shared structs and shared
strings can be worked on in parallel.
Bug: v8:12007
Change-Id: Ic849ec66da1d3824d50d695f16e4b77380afa015
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379222
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78570}
We introduce a type arrayref, which is a supertype of all array types
and a subtype of dataref. We change array.len to accept values of type
(ref null array).
Drive-by: Fix kEq/kData case in TypecheckJSObject.
Bug: v8:7748
Change-Id: I47c6a4487ddf5e7280c1427f43abe87a97c896bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368105
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78565}
- Add Suspender.suspendOnReturnedPromise method
- Extend the WasmApiFunctionRef data with the suspender
- Detect wrapped WasmJSFunctions when we resolve the import
For now the generated wrapper is still a regular wasm-to-js wrapper, but
this sets the ground for generating specific wrappers for functions
wrapped by suspendOnReturnedPromise, and to access the suspender from
the wrapper code.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: I81cbec6b023507e47e6e1463b5f9b912f807da6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345000
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78560}
When creating a new JSError object (or using the non-standard API
`Error.captureStackTrace`) V8 would previously capture the "simple stack
trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
standard `error.stack` property, and if the inspector was active also
capture the "detailed stack trace" (as FixedArray of StackFrameInfo
instances). This turns out to be quite a lot of overhead, both in terms
of execution time as well as memory pressure, especially since the
information needed for the inspector is a proper subset of the
information needed by `error.stack`.
So this CL addresses the above issue by capturing only the "simple stack
trace" (in the common case) and computing the "detailed stack trace"
from the "simple stack trace" when on demand. This is accomplished by
introducing a new ErrorStackData container that is used to store the
stack trace information on JSErrors when the inspector is active. When
capturing stack trace for a JSError object while the inspector is
active, we take the maximum of the program controlled stack trace limit
and the inspector requested stack trace limit, and memorize the program
controlled stack trace limit for later formatting (to ensure that the
presence of the inspector is not observable by the program).
On the `standalone.js` benchmark from crbug.com/1283162 (with the
default max call stack size of 200) we reduce execution time by around
16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
regression in crbug.com/1280831), we are 6% faster now.
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Bug: chromium:1280831, chromium:1278650, chromium:1258599
Bug: chromium:1280803, chromium:1280832, chromium:1280818
Fixed: chromium:1283162
Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78542}
We unify the implementation of element segment expression entries with
other initializer expressions: we represent them with a {WireBytesRef}
and decode them with {InitExprInterface}. Except for reducing code
duplication, this also fixes a bug where {global.get} entries in element
segments could reference invalid globals.
Changes:
- Change {WasmElemSegment::Entry} to a union of a {WireBytesRef}
initializer expression and a {uint32_t} function index.
- In module-decoder, change parsing of expression entries to use
{consume_init_expr}. Add type checking to
{consume_element_func_index}, to complement type checking happening in
{consume_init_expr}.
- In module-instantiate.cc:
- Move instantiation of indirect tables before loading of element
segments. This way, when we call {UpdateDispatchTables} in
{SetTableEntry}, the indirect table for the current table will also
be updated.
- Consolidate table entry instantiation into {SetTableEntry}, which
handles lazily instantiated functions, or dispatches to
{WasmTableObject::Set}.
- Rename {InitializeIndirectFunctionTables} to
{InitializeNonDefaultableTables}.
- Change {InitializeNonDefaultableTables} and {LoadElemSegmentImpl}
to use {EvaluateInitExpression}.
- Add a test to exclude mutable/non-imported globals from the element
section.
- Update tests as needed.
- Update .js module emission in wasm-fuzzer-common.
Change-Id: I29c541bbca8531e8d0312ed95869c8e78a5a0c57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364082
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78476}
See related CL for context.
Changes:
- In InitExprInterface, add the ability to evaluate function references
as index only. Remove the global buffers and use the ones passed with
the instance object instead.
- In WasmElemSegment, add a field indicating if elements should be
parsed as expressions or indices. Change module-decoder.cc to reflect
this change.
- In module-instantiate, change the signatures of LoadElemSegment,
LoadElemSegmentImpl, and EvaluateInitExpr. Move the latter out of
InstanceBuilder.
Change-Id: I1df54393b2005fba49380654bdd40429bd4869dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364081
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78470}
Wasm values are stored in memory in little endian order even
on BE machines and as a result they need to be manually reversed
after a load.
Other such atomic ops get patched during Wasm compilation or
during code-gen, this is one of the few places where a runtime call is
made to C++ which requires this fix.
As the the runtime stub is used on both TurboFan and Liftoff this
patch will fix both cases.
Up until now the cctest was passing incorrectly as it's mixing the
Wasm memory buffer with TypedArrays. TypedArrays don't have the
LE enforcement and use the native byte order.
With this patch the test is now failing as expected
and is being skipped for now.
Bug: v8:12505
Change-Id: I49fac208f1fab7396b7d9911e803bc047b3b8263
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350744
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78433}
Initialize the (thread-local) memory protection key permissions for any
isolate that joins the wasm engine. Otherwise it can happen that an
isolate gets Wasm code from the cache without ever compiling anything
(hence without ever changing memory protection key permissions), and
then it would not be allowed to access (read or execute) the code.
I tested this change manually on a PKU-enabled devices. The new test
crashed before the fix, and completes successfully afterwards.
R=ahaas@chromium.org
Bug: v8:11974, chromium:1280451
Change-Id: I90dded8b4fdaa8cf34b44107291d3f525ce16335
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3347563
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78413}
... in order to avoid Code <-> CodeT conversions in builtins.
This CL changes the meaning of RelocInfo::CODE_TARGET which now expects
CodeT objects as a code target.
In order to reduce code churn this CL makes BUILTIN_CODE and friends
return CodeT instead of Code. In the follow-up CLs BUILTIN_CODET and
friends will be removed.
Bug: v8:11880
Change-Id: Ib8f60973e55c60fc62ba84707471da388f8201b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338483
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78393}
When compiled with gn argument 'is_debug=false' these tests fail on
Windows due to the fact that they're compiled with '/guard:cf'.
This CL changes the use of FUNCTION_CAST to GeneratedCode::Call which
contains DISABLE_CFI_ICALL attribute. This is analogous to how
assembled functions are called in Assembler tests for other
architectures.
Change-Id: I330e29a508ad1421cb98dea3d9761f05272ab763
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3341511
Auto-Submit: Dmitrii Tsykunov <dtsykunov1@yandex-team.ru>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78386}
This CL renames a number of things related to the V8 sandbox.
Mainly, what used to be under V8_HEAP_SANDBOX is now under
V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
is now simply the V8 Sandbox:
V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
V8VirtualMemoryCage => Sandbox
CagedPointer => SandboxedPointer
fake cage => partially reserved sandbox
src/security => src/sandbox
This naming scheme should simplify things: the sandbox is now the large
region of virtual address space inside which V8 mainly operates and
which should be considered untrusted. Mechanisms like sandboxed pointers
are then used to attempt to prevent escapes from the sandbox (i.e.
corruption of memory outside of it). Furthermore, the new naming scheme
avoids the confusion with the various other "cages" in V8, in
particular, the VirtualMemoryCage class, by dropping that name entirely.
Future sandbox features are developed under their own V8_SANDBOX_X flag,
and will, once final, be merged into V8_SANDBOX. Current future features
are sandboxed external pointers (using the external pointer table), and
sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
because they are encoded as offsets). This CL then also introduces a new
build flag, v8_enable_sandbox_future, which enables all future features.
Bug: v8:10391
Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
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/+/3322981
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78384}
This is a non-functional refactoring to make naming of stack traces more
consistent, and thus easier to reason about whether the "simple stack
trace" (stack trace API) or the "detailed stack trace" (inspector API)
is meant. Granted, these names aren't great by themselves, but at least
we should be consistent.
This also adds a new `Isolate::GetSimpleStackTrace()` and uses that
directly to implement the Wasm C-API, avoiding the roundtrip via the
`JSMessageObject`, which actually carries a detailed stack trace (which
by chance worked out so far).
Doc: https://bit.ly/v8-stack-frame
Bug: chromium:1258599, chromium:1278647, chromium:1278650
Change-Id: I29e1a956ed156d6eeceb50150a28afaa2f11b9c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3334780
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78366}
This is the second step in the refactoring to make v8::StackFrame
more lightweight and usable for (long time storage) by the V8
inspector (see https://bit.ly/v8-stack-frame for an overview).
This is a purely mechanical change without any functional aspects.
The intention is to make the use case for the CallSiteInfo objects
clear, namely to serve as the backing store for the CallSite objects
exposed via the Error.prepareStackTrace() API and used under the
hood to implement the error.stack accessor.
Doc: https://bit.ly/v8-stack-frame
Bug: chromium:1258599, chromium:1278647, chromium:1278650
Change-Id: I39dffd1f1a8e5158ddc56f2a0a2b1b28321f487a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300138
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78361}
Since the reftypes proposal has shipped, we remove the respective flag
and the code that handled its absence. We maintain a WasmFeature for
reftypes for feature detection purposes. We remove the flag declaration
from tests, and adapt some tests that make no sense without the flag.
Bug: v8:7581
Change-Id: Icf2f8d0feae8f30ec68d5560f1e7ee5959481483
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329781
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78351}
This allows us to reuse AstValueFactory's string table across multiple
parsers, while still releasing memory after each individual parse.
This is mild overkill for all the single parses that don't reuse
AstValueFactories, but there at least the AstRawStrings now end up
grouped together in memory, so that might have mild cache benefits.
Change-Id: I0b378760b601fa4ec6559a0dca5d7ed6f895e992
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322764
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78338}
Rather than requiring the user of a LocalIsolate to pass in a
RuntimeCallStats from a WorkerThreadRuntimeCallStatsScope, create the
scope in the LocalIsolate directly and use its RuntimeCallStats in the
LocalIsolate constructor.
We can't do this for the main thread LocalIsolate, since
WorkerThreadRuntimeCallStatsScope doesn't work on the main thread, so
there we use the main-thread RuntimeCallStats instead.
This flushes out some issues of background-thread LocalIsolates being
used on the main thread, so fix those too, as well as RCS scopes using
background counters for operations that could happen on the main thread.
Change-Id: I21a53be0771f47a03ccdb27d24c2b9d25d8b2d1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318664
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78334}
This reverts commit 91f08378bc.
Reason for revert: It's a fairly big change, and the clusterfuzz
found some bugs. Will reland with the fix after M98 branch point.
Original change's description:
> [class] implement reparsing of class instance member initializers
>
> Previously, since the source code for the synthetic class instance
> member initializer function was recorded as the span from the first
> initializer to the last initializer, there was no way to reparse the
> class and recompile the initializer function. It was working for
> most use cases because the code for the initializer function was
> generated eagarly and it was usually alive as long as the class was
> alive, so the initializer wouldn't normally be lazily parsed. This
> didn't work, however, when the class was snapshotted with
> v8::SnapshotCreator::FunctionCodeHandling::kClear,
> becuase then we needed to recompile the initializer when the class
> was instantiated. This patch implements the reparsing so that
> these classes can work with FunctionCodeHandling::kClear.
>
> This patch refactors ParserBase::ParseClassLiteral() so that we can
> reuse it for both parsing the class body normally and reparsing it
> to collect initializers. When reparsing the synthetic initializer
> function, we rewind the scanner to the beginning of the class, and
> parse the class body to collect the initializers. During the
> reparsing, field initializers are parsed with the full parser while
> methods of the class are pre-parsed.
>
> A few notable changes:
>
> - Extended the source range of the initializer function to cover the
> entire class so that we can rewind the scanner to parse the class
> body to collect initializers (previously, it starts from the first
> field initializer and ends at the last initializer). This resulted
> some expectation changes in the debugger tests, though the
> initializers remain debuggable.
> - A temporary ClassScope is created during reparsing. After the class
> is reparsed, we use the information from the ScopeInfo to update
> the allocated indices of the variables in the ClassScope.
>
> Bug: v8:10704
> Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#78299}
Bug: v8:10704
Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328
Auto-Submit: Joyee Cheung <joyee@igalia.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78315}
