Introduces getEnclosingColumn and getEnclosingLine on CallSite
so that the position can be used to lookup the original symbol
for function when source maps are used.
BUG=v8:11157
Change-Id: I06c4c374d172d206579abb170c7b7a2bd3bb159f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2547218
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benjamin Coe <bencoe@google.com>
Cr-Commit-Position: refs/heads/master@{#71343}
If we have a regular isolate (or none at all), we can skip acquiring
the lock check and DCHECK that we are calling from the main thread.
If we have a LocalIsolate, we acquire the string lock if needed.
Bug: v8:7790
Change-Id: Ie3562e8172a3e3eca8d194e8652cb881f765cdb8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2551102
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71340}
We use the same temporary mechanism as with eqref, in anticipation of
standardization of the wasm-gc JS API.
Bug: v8:7748
Change-Id: I224a043e5450ce489fc7f3b2f07f277a0444b8e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546695
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71339}
This changes a '<' to a '<=' and adds a comment to explain why it is
safe to use a jump table where the maximum distance is exactly
{kMaxCodeSpaceSize}.
R=jkummerow@chromium.org
Bug: chromium:1151364
Change-Id: Id4971a2e9095fa99df48367ab09af4adbfadffaf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2552906
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71337}
For a very particular special case (long "chains" of bound
functions with an undefined @@hasInstance handler), evaluating
the `instanceof` operator could lead to a very deep recursion.
This patch adds a stack check to make sure we throw rather than
crash on stack overflow.
Bug: v8:11115
Change-Id: I6bf941b9e75e9fe3a52112ade27388ac4fbbda2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545624
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71335}
Bug: v8:7790
Change-Id: Idee149b3d59064941473d5e17e2c56a253a5f49d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546691
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71334}
Don't pass the correctness-fuzzing suppressions to normal fuzzing as
they turn stack overflows and invalid string length checks into
crashes.
This became first now a problem after the flag was passed in an mjsunit
test case.
No-Try: true
Bug: chromium:1151600,chromium:1151599
Change-Id: I5d29900a4b155762cae447fc102055eab1916309
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2551112
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71333}
I'm working for Loongson Technology, and I have contributed 120+
patches to maintain v8 on mips platform. I request to be an owner
of MIPS files, so that we can maintain mips ports more conveniently.
Change-Id: Ib01dadfb879fefe7c095398930573e8df0f7c8dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2525542
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71332}
When comparing two-byte strings, the correct number of characters to
compare is length(), not byte_length().
The bug was introduced in
https://chromium-review.googlesource.com/c/v8/v8/+/2533038
There's no regression test, since going beyond the AstRawString
boundary generally doesn't crash.
Bug: chromium:1151602
Change-Id: I32c297c2751835dd7574ff928d2d5b8346b4381a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2551110
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71330}
Rolling v8/build: ee1c001..030a312
Rolling v8/third_party/aemu-linux-x64: 4f-YWuHlGrqS9jy308GUs0eo8DxU3h6PwgpHfNYq290C..gt2DKWmtJU6vqOju1UcBB-_Nthud81s3cnZkERzzSEUC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2ed6fc0..11b4013
Rolling v8/third_party/depot_tools: 2f8e0fa..9c0dc30
Rolling v8/third_party/zlib: e84c9a3..9893e50
Rolling v8/tools/luci-go: git_revision:1a022d3a4c50be4207ee93451255d71896416596..git_revision:6cbe3f56e9f00b8f65eae21f01838a8b58191a47
Rolling v8/tools/luci-go: git_revision:1a022d3a4c50be4207ee93451255d71896416596..git_revision:6cbe3f56e9f00b8f65eae21f01838a8b58191a47
Rolling v8/tools/luci-go: git_revision:1a022d3a4c50be4207ee93451255d71896416596..git_revision:6cbe3f56e9f00b8f65eae21f01838a8b58191a47
TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: Ia6309934987cdc0f0da95a83875041761673ec3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2553156
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#71326}
Without the cast, gcc might throw the following error
during compilation:
error: enumeral mismatch in conditional expression:
'cppgc::internal::StatsCollector::ScopeId' vs
'cppgc::internal::StatsCollector::ConcurrentScopeId'
Change-Id: I95e230310a0cbdc775d63657b8c407a8392a57e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2551104
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71325}
Drive-by: Add alias for lzer on Assembler
Change-Id: Id0d705ef864899241f77d92c2cf8a144f753ef15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2552928
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71324}
With pointer compression, the size of a reference depends on whether it
is stored on the stack or on the heap. The size provided by
ValueType::element_size_bytes() is the size of a reference on the heap.
LiftoffAssembler::SlotSizeForType(...) however should return the size
on the stack. This CL fixes this inconsistency.
This issue would have been found by an existing test, but this test is
disabled at the moment because of missing safepoint maps for stack
checks.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: Ia45944b265fa4ce0d560ff00a24b023d6c1ae10a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2552515
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71320}
Because of LocalHeap safepoints, our existing assert scopes don't
necessarily maintain the same guarantees as desired. In particular,
DisallowHeapAllocation no longer guarantees that objects don't move.
This patch transitions DisallowHeapAllocation to
DisallowGarbageCollection, to ensure that code using this scope is
also protected against safepoints.
Change-Id: I0411425884f6849982611205fb17bb072881c722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71319}
This retrieves script name directly from StackFrameBase, bypassing
building of StackFrameInfo if one hasn't already been initialized,
thus avoiding computation of expensive properties that are not required.
This matches current behavior of GetScriptNameOrSourceURL() and is a
workaround until a dedicated API is available.
This is necessary to switch AdTagging over from using
GetScriptNameOrSourceURL() to GetScriptName(), to ensure that scripts
with source urls are tagged appropriately. (See crrev.com/c/2551259.)
Bug: chromium:1127391
Change-Id: I6eb145b88c26deb1a088f038b0f8b377bc8fe3ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2550504
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Alex Turner <alexmt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71318}
Port 1da429fb8a
Original Commit Message:
This is a reland of 800307f6a5, with a
minimal fix for arm64 (uint64_t -> uintptr_t).
Original change's description:
> [wasm][memory64] Prepare Liftoff for ptrsize offsets
>
> This CL prepares the LiftoffAssembler interface for uintptr_t offsets.
> Many places can still only handle 32-bit values, but after this CL we can
> start storing the offsets as uintptr_t in the memory access immediates.
> Some TODOs are placed to extend code generation for 64-bit additions, if
> memory64 is enabled.
> All of this will be addressed in follow-up CLs.
>
> R=manoskouk@chromium.org
>
> Bug: v8:10949
> Change-Id: Id3b9b8aa555ab41f082ba012f4f8d80586c35b89
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529452
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71236}
R=clemensb@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I87a421ab1fe6e4d0f2098c24ff34a3888631722e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2552166
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71317}
CalculateGlobalOffsets has to be called once after all globals got
defined but before global offsets get accessed, e.g. during code
generation. It is not clear though when exactly CalculateGlobalOffsets
should be called. The globals section may not exist, so at the end of
the globals section is not enough (globals can also be defined in the
import section). At the beginning of the code section is also not good
enough, because the code section may not exist. At the end of the module
may be too late.
With this CL, CalculateGlobalOffsets is called after the global section,
before the code section, and at the end of the module. Additionally the CL
checks if CalculateGlobalOffsets has already been called, so that it is
not executed a second time.
R=manoskouk@chromium.org
Bug: v8:11185
Change-Id: I922b9f60a4a17a09d2527fd9ab35cda71226030c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2551100
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71314}
Changes:
- Move enhancement of locals_count by 1 inside AnalyzeLoopAssignment.
- Update documentation of AnalyzeLoopAssignment.
- Factor out invocation to OpcodeLength();
- Use uint32_t for locals count consistently in related testing
functions.
Change-Id: I5bb5a324c4f4ed1aafc37849f3762d7a9630da51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2549966
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71312}
This CL adds partial support for objects whose slow mode dictionaries
are OrderedNameDictionaries. This is the case for all slow mode objects
if V8_DICT_MODE_PROTOTYPES is enabled.
Specifically, this CL contains bailouts to the runtime in places where
the subsequent CSA or Torque code may have to access property
dictionaries.
These bailouts only happen if V8_DICT_MODE_PROTOTYPES is set, in which
case the property dictionaries are of type OrderedNameDictionary, which
cannot be handled by most CSA/Torque code.
The idea is that these bailouts are temporary and will all be removed
once we've implemented the actuall dictionary accesses in CSA/Torque.
Bug: v8:7569, v8:11167
Change-Id: I8308b2f8ba2d4dbf7918da42f995ae270c825fff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545711
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71311}
Reset main_thread_local_isolate_ only after Heap::TearDown was executed.
main_thread_local_isolate_ is still needed in there for e.g.
HandleBase::IsDereferenceAllowed in MemoryMeasurement.
Bug: chromium:1150867, v8:10315
Change-Id: Ia1ebfd561b7a3ab2d346f0c17b239f75ad77471f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2549969
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71310}
This is a reland of e26863df27
The test now works with the no-i18n case.
Original change's description:
> [foozzie] Suppress access to CurrentTimeValue
>
> This stubs out CurrentTimeValue for differential fuzzing as otherwise
> the non-deterministic value leaks from Intl.DateTimeFormat format and
> formatToParts.
>
> This also affects other date creations, like Date.now(), which is
> already stubbed out on the JS side. We keep that code for
> backwards-compatibility to keep bisection stable.
>
> Bug: chromium:1149050
> Change-Id: Ifd82844c9fb8ce7262b55da6cf9f88f544268942
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546685
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71294}
Cq-Include-Trybots: luci.v8.try.triggered:v8_linux_noi18n_rel_ng_triggered
Bug: chromium:1149050
Change-Id: I4a750b580495532ca0ffb125522f8f5958e4cad6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2552401
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71309}
We had a test which first enabled the profiler, and then compiled wasm
code. In this case, all code objects were registered correctly and the
profile looked as expected.
This CL extends the test for also test another order: First compile the
wasm code, then enable the profiler. In that case, we were reporting a
wrong debug name of the exported wasm function. The name of that
function is spec'ed to be the string representation of the function
index. But for debugging, we want to see a more meaningful name,
identical to the name we show when reporting the code during
compilation.
This fix requires handlifying the {SharedFunctionInfo::DebugName}
method, because for exported wasm functions, it needs to allocate a new
name on the JS heap.
In order to avoid this allocation where possible, a second variant is
added which returns a unique_ptr directly. This can be used in all
places where the name is just being printed, which turned out to be the
majority of cases ({DebugName().ToCString()}).
R=petermarshall@chromium.org
Bug: chromium:1141787
Change-Id: I0343c2f06f0b852007535ff07459b712801ead01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543931
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71308}
This is a reland of 800307f6a5, with a
minimal fix for arm64 (uint64_t -> uintptr_t).
Original change's description:
> [wasm][memory64] Prepare Liftoff for ptrsize offsets
>
> This CL prepares the LiftoffAssembler interface for uintptr_t offsets.
> Many places can still only handle 32-bit values, but after this CL we can
> start storing the offsets as uintptr_t in the memory access immediates.
> Some TODOs are placed to extend code generation for 64-bit additions, if
> memory64 is enabled.
> All of this will be addressed in follow-up CLs.
>
> R=manoskouk@chromium.org
>
> Bug: v8:10949
> Change-Id: Id3b9b8aa555ab41f082ba012f4f8d80586c35b89
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529452
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71236}
Bug: v8:10949
Tbr: manoskouk@chromium.org
Change-Id: I33a9676afbf84d2032b181de2afd745841575900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2550663
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71307}
We added this to add elements kind to handlers so Turboprop could
use the elements kind information for inlining array builtins when using
dynamic map checks. This information isn't useful without other map
based optimizations like constant folding to inline array builtins.
So we don't need this information.
Bug: v8:10582
Change-Id: I846c037ca2d87158dd017e2e23c7d1a0dfc685b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2549950
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71306}
This CL adds partial support for objects whose slow mode dictionaries
are OrderedNameDictionaries. This is the case for all slow mode objects
if V8_DICT_MODE_PROTOTYPES is enabled.
Specifically, this CL contains minor changes to CSA code, short of
actually performing ordered dictionary lookups using CSA
implementations of these lookups.
Bug: v8:7569
Change-Id: I0dab0f21000ca3b9b170ace58787ec639d587e64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540590
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71304}
We had some tests, but weren't checking for OOB. Add some tests.
Change-Id: I63d4d199fe8b7be51a8e0a5a2d9b3a328e5d7ab5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546127
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71302}
LocaleBuilder validates better, it also fixes most cases in
transformed-ext-invalid except one.
Bug: v8:10447
Change-Id: I6fed6692ca3264198e42ccc3d9ca4bfb54fb0517
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2549688
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71300}
This reverts commit e26863df27.
Reason for revert: Fails on noi18n bot, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/34852/overview
Original change's description:
> [foozzie] Suppress access to CurrentTimeValue
>
> This stubs out CurrentTimeValue for differential fuzzing as otherwise
> the non-deterministic value leaks from Intl.DateTimeFormat format and
> formatToParts.
>
> This also affects other date creations, like Date.now(), which is
> already stubbed out on the JS side. We keep that code for
> backwards-compatibility to keep bisection stable.
>
> Bug: chromium:1149050
> Change-Id: Ifd82844c9fb8ce7262b55da6cf9f88f544268942
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546685
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71294}
TBR=machenbach@chromium.org,cbruni@chromium.org,clemensb@chromium.org
Change-Id: I958ca723de826ab427d27f5121f96618cf50c832
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1149050
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2551314
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71298}
The basic block instrumentation currently uses 32-bit integers, which
could overflow during a long profiling session. I considered upgrading
them to 64-bit integers, but generating the correct instrumentation code
for various architectures would be rather non-trivial. Instead, this
change uses 64-bit floating-point values, which are simple and also have
the nice behavior that they saturate rather than overflowing.
Bug: v8:10470
Change-Id: I60f7456cb750091809803c03a85dd348dc614b58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545573
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71297}
