After computing the branch offset but before emitting the actual branch,
we should not emit a constant pool. Otherwise the previously computed
offset would be off.
Instead of handling this indirectly via the Assembler::branch_offset
method, do this directly in the Assembler::b method (and friends), so it
is not missed on other call sites.
R=jkummerow@chromium.org
Bug: chromium:1399424
Change-Id: I0cbb219ced5b671001a296b1cc7c339f395abffe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4102800
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84828}
Currently, any session can resume instrumentation breaks by sending
Debugger.resume command. That can lead to unreliable breakpoint
placement because sessions can resume too early.
The early resumption can happen in two ways:
- When we have two instrumented sessions, the first one to resume
can prevent the other one from setting its breakpoints
before executing the code.
- With one instrumented session and one without instrumentation
breakpoints, the uninstrumented session's Debugger.resume
command can resume the instrumentation pause before the
instrumented session can set its breakpoints.
This patch fixes both of these issues by changing the instrumentation
pause resumption logic to take note of the sessions that were notified
about the instrumentation breakpoints. The debugger will only resume
once all those sessions resume (or disconnect).
Bug: chromium:1354043
Change-Id: I84cf16b57187dbb40645b2f7ec2e08f0078539dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100466
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84827}
This CL adds v8::ArrayBuffer::NewResizableBackingStore.
This API is needed to support Mojo cross-process serialization of
resizable buffers. See https://chromium-review.googlesource.com/c/chromium/src/+/4086949
Bug: chromium:1396361, v8:11111
Change-Id: I1d3ad367f28015184fd80fd2f05a37a3659d3a66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4093555
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84826}
Asm.js code (translated to Wasm) is valid by design, do not try to
validate it.
This is achieved by fully populating the {validated_functions} bitset
for asm.js modules. To make this safe(r) we do not allow to change the
origin or a WasmModule after initialization, which requires some
refactoring mostly in tests.
R=ahaas@chromium.org
Bug: v8:13447, v8:13565
Change-Id: I174c01f13185ff4117b02882b953c6ba29a3644d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100686
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84824}
There were compile errors when building v8 with v8_enable_precise_zone_stats = true.
../../src/zone/type-stats.cc:30:24: error: no type named 'Free' in namespace 'v8::base'
if (buffer_) base::Free(buffer_);
../../src/zone/zone.h:255:3: error: use of undeclared identifier 'stdd'; did you mean 'std'?
stdd::atomic<size_t> freed_size_for_tracing_ = {0};
Bug: v8:10572
Change-Id: If1035edc99eff05c418e0bc65de8a8729f75e30f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4098379
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84822}
This is necessary to allow running GC epilogue callbacks after a
GC in the safepoint. Handle dereferences are allowed even if that
particular thread is parked. They may generally also happen from a
different thread than expected by DCHECKs in the case shared GCs
combined with multiple main threads.
This CL solves this issue by adding an additional assertion scope
that can temporarily allow such derefs for running the callbacks.
Unlike other assert scopes the new assert scope is disabled by
default.
Bug: v8:13267, chromium:1399379
Change-Id: Ibc741ad6bebb740cf24ae8be116d770f62ae6481
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100826
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84821}
According to the style guide, field definitions should be the last thing
in the private section.
R=ahaas@chromium.org
Change-Id: I2b0890b7f5f5c8a9a19213a80c400bd9db080a05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4097429
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84820}
AffectedFile.LocalPath returns a path with backward slashes in Windows. Update the presubmit script to handle this case properly.
Bug: v8:13582
Change-Id: Iabc46ded5a8448e5d373679162108f94846c06e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4099007
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#84819}
Build mode for serializing the read only heap as a memory dump in the
startup snapshot. This makes compressed pointers of root objects
statically known at mksnapshot time.
This CL also adds a feature to mksnapshot to dump the static addresses
to a C++ header file. This will allow us to use these addresses in the
future.
The mode is disabled for now since we need some build infrastructure
first to conveniently re-generate the table when the layout changes.
Bug: v8:13466
Change-Id: I975b15bd89fedf713fb7d12b4929935ece78139d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4056181
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84815}
This reverts commit 303facf5e1.
Reason for revert: Causes failures with fuzzers.
Original change's description:
> [heap] Also promote strings in large objects into shared heap
>
> With --shared-string-table all in-place internalizable strings are
> directly promoted from new space into the shared heap. However, this
> wasn't the case with large objects. This CL fixes this and adds test
> to guide fuzzers.
>
> Bug: v8:13267, chromium:1400048
> Change-Id: I6f850d480956c63bfbe1a7060140df850e284933
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096818
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84805}
Bug: v8:13267, chromium:1400048
Change-Id: If20528bbf804b73ce8ad10f8addc9a1f11b50d96
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4101261
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84813}
This will allow bugs such as crbug.com/1394403 to be found much easier
by fuzzers as it will cause d8 to compile every function twice and to
verify that the resulting bytecode is the same.
In order to not lose fuzzer coverage of e.g. lazy compilation, this CL
also adds --lazy and --no-stress-lazy-source-positions to the fuzzer
configurations to be chosen with a small probability.
Bug: chromium:1394403
Change-Id: I172ac483b45978a669c9787e5f851daa985fd1f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096480
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84811}
The "is there enough data" check has to be done *after* reading
maxByteLength.
Bug: v8:11111, chromium:1400431
Change-Id: I7c2eddaeb998f3cd3919e118c093a5d036fca408
Fixed: chromium:1400431
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100468
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84809}
The {Assembler::emit_operand} method is basically just copying 1-6 bytes
from {Operand::Data::buf} into the assembler buffer. This showed up with
>5% of Liftoff compilation time in a performance profile.
This CL makes this >2x faster by using an optimized copying routine
(using the same trick that libc's memcpy uses).
R=jkummerow@chromium.org
Bug: v8:13570
Change-Id: I525a94989c271b56ad7c148d21f234d05a25842a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4088606
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84807}
With --shared-string-table all in-place internalizable strings are
directly promoted from new space into the shared heap. However, this
wasn't the case with large objects. This CL fixes this and adds test
to guide fuzzers.
Bug: v8:13267, chromium:1400048
Change-Id: I6f850d480956c63bfbe1a7060140df850e284933
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096818
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84805}
Code objects are linked in a custom per-native-context weak list of
optimized code (previously there was also a list of deoptimized code,
but this was recently removed).
There used to be reasons for this list, but at this point it is only
used by the debugger to mark code for deoptimization. The debugger can
do this with a heap walk instead, so we can remove this list and indeed
the next_code_links from Code objects themselves.
Change-Id: Iebbed4adacd31b8ddc442ae6355ea45c691cc856
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061515
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84804}
The "negative" instructions `br_on_non_*` & `br_on_cast_fail` created
the `TypeGuard` node for the successful branch using the effect /
control chain o fthe wrong branch.
As `TypeGuard`s do not generate code, these instructions are for the
Turbofan type system.
Bug: v8:7748
Change-Id: I12de7421a6d16e24d91336457443ab6f646ab309
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4097425
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84802}
We received feedback that the [[Scopes]] property has some legitimate
use-cases not covered by the Scopes View during pause.
We re-enable the feature for now and will remove the flag in a
follow-up.
R=bmeurer@chromium.org
Bug: chromium:1365858
Change-Id: Ibf279ae6c4f5ae492d03e9b4ee7316f6500508d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4099385
Auto-Submit: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84800}
In case a JSArrayBuffer is empty but has an extension installed, the
previous code would not clear the extension prior to serialization. This
would then cause a DCHECK failure right after serialization when
restoring the extension pointer because we only allow changing from
nullptr to a non-null extension pointer.
Bug: chromium:1335043
Change-Id: I9276da0ebb7ecf0d22949c3d1294cfa90bad7a7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096479
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84798}
This patch moves the stop method from context group to session to enable
stopping each session independently. This is useful for testing that
stopping does not interact badly with other sessions.
Bug: chromium:1354043
Change-Id: I885cf49f2d4cf006fa5228edf2954099e45cfc6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100484
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84797}
When loading a 32-bit value from the stack, just load 32 bit and
zero-extend them into the target register, instead of loading the full
64 bits.
As there are things to fix (see https://crbug.com/1356461), we only
enable this optimization for Wasm for now.
R=jkummerow@chromium.org
Bug: chromium:1395604, chromium:1356461, v8:13581
Change-Id: Ibdd2d80704973362906aec9b38faa762d3b43f3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4097424
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84796}
gcc versions < 9 may produce the following compilation error due
to passing/initializing an empty struct as a parameter:
> '<anonymous>' is used uninitialized in this function
A reproducible code sample can be seen here:
https://godbolt.org/z/PfanPrEGG
This issues seems to have come up in gcc in various ways,
here is a related bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465
A simple workaround here it to add a 0 initialized value to
the empty struct.
More information can be found at the comment section of this CL: crrev.com/c/4057111
Bug: v8:12783
Change-Id: Iee8fec73610fa2525530db431daf5fa285c09a3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4097624
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#84795}
This CL fixes two bugs:
- The monotonicity violation in the typers of ToBigIntConvertNumber and
Integral32OrMinusZeroToBigInt.
- The missing handling of conversion from Tagged output with the type
DoubleRepresentableInt64OrMinusZero to Word64.
Bug: v8:9407, v8:13580, chromium:1399951, chromium:1400053
Change-Id: I669820b52e5b82bddc9853cfd97a2361c344a2cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096990
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84793}
We already exclusively use the WasmEngine's AccountingAllocator for all
decoded Wasm modules. Except for tests, the same allocator will also be
used for validation. Thus do not pass it down explicitly, but get it
from the WasmEngine when needed.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: Idaa9d6c3e0ab0051bf85bb2667accac89e8b5607
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092738
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84792}
In synchronous mode, a TF compilation can trigger a lazy
deopt of the Maglev code.
Instead, if in synchronous mode, we eager deopt to Ignition
and OSR from there.
Fixed: chromium:1394279
Bug: v8:7700
Change-Id: I4db2ac561d5626ab5f04b167e50025013490a4a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096878
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84790}
This replaces the dummy values for the crash analysis. We use the
stack parser from ClusterFuzz to extract the crash type and state from
the stderr of the output and we store it in the test results. We also
added some tests to check the functionality with some example stderrs.
Bug: v8:12313
Change-Id: I67994a752a7aa01cacfb7ebfe7e9d3d61820a4dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067428
Reviewed-by: Liviu Rau <liviurau@google.com>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84789}
JetStream2:ARES:Basic regresses with the Float64Exponentiate.
It seems that calling the builtin directly is cheaper than
unboxing both inputs and calling the C++ stub.
Bug: v8:7700, v8:1393643
Change-Id: Ib2c1523ed57eea048bb269fc16992349687cbb73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4084764
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84786}
A new test added in https://crrev.com/c/4092575 times out on ASan
windows builds and is slow.
Superseeds https://crrev.com/c/4096677.
No-Tree-Checks: true
No-Try: true
Bug: v8:13466
Change-Id: I40d61459437434cf739fbff8c223871012a23010
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096817
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84784}
The current reduction of blocks that are branch targets with a known
condition assumes that this is the first time we're seeing the given
condition with the given value. That's no longer the case, so updating
the expectation accordingly.
Bug: chromium:1399627
Change-Id: Id84d80a38801cf6178b476e62160d616b948d8d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096984
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84780}
