This CL adds support for anyref in WebAssembly.Global objects. Note
that the specification is not complete yet in this area.
I did the following changes:
- I renamed the `array_buffer` field of WasmGlobalObject to
`untagged_buffer`
- I added an additional field of type FixedArray, `tagged_buffer`.
- In the constructor of WasmGlobalObject I allocate either the former
or the latter, but not both.
- In the WebAssembly.Global constructor I added special handling for
the case where no initial value is provided. In that case I set the
inital value to `null` and not to `undefined`.
R=titzer@chromium.org
Bug: v8:7581
Change-Id: I7e4855d7e6c04a9bcdc7ebd450caca5819d060e2
Reviewed-on: https://chromium-review.googlesource.com/c/1398226
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58625}
If we have both f32 and f64 locals, we use the same register to hold
their zero value. On stack transfers, we might thus encounter the same
fp register with both the f32 and f64 type. Explicitly allow that case
to happen.
R=ahaas@chromium.org
Bug: chromium:918917, v8:6600
Change-Id: I6937008d38853fe2bdccd9715e1a2499cf6bf7c6
Reviewed-on: https://chromium-review.googlesource.com/c/1398225
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58623}
On ia32, the instruction selector uses movsx_b to compile the wasm
SignExtendWord8ToInt32 instruction. movsx_b requires a byte register
as input. However, not all allocatable registers on ia32 are. As we
cannot currently express constraints on subsets of registers, this
change now forces the input to movsx_b into eax.
Bug: chromium:919572
Change-Id: I39bd391974954ec9044940c3164398109eb78908
Reviewed-on: https://chromium-review.googlesource.com/c/1400409
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58622}
Two uses in the API needed adaptation; all other uses have already
been subsumed by the new implementation (previously known as
NeverReadOnlySpaceObjectPtr, here renamed to NeverReadOnlySpaceObject).
Bug: v8:3770
Change-Id: Idf0e4a98a407b9afea22e8790da34cf017b892a5
Reviewed-on: https://chromium-review.googlesource.com/c/1397671
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58620}
StackHandlers form a chain, where the last element is nullptr,
so calling "handler->next()->foo()" is unsafe because "foo"
might see "this == nullptr".
Bug: v8:3770
Change-Id: Ic989384fa192e29d4d8cb76ff01b32173bf55fd9
Reviewed-on: https://chromium-review.googlesource.com/c/1400406
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58619}
This CL prevents redundancy elimination from widening types, which
can cause problems if the input of a DeadValue (which has type None)
is replaced by an equivalent node that does not have type None. This
can happen because load elimination does not re-type nodes, for
example.
Bug: chromium:919340
Change-Id: I89e872412edbcdc610e70ae160cde56cd045006c
Reviewed-on: https://chromium-review.googlesource.com/c/1397709
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58617}
Prior to this CL compilation fails with:
- 'error: offset of on non-standard-layout type' due to offsetof()
- 'Assertion failed: vector subscript out of range' due to the OOB vector subscripts
Change-Id: I8751fafd1058ca839de832267811f8f1f47c53fe
Reviewed-on: https://chromium-review.googlesource.com/c/1400404
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58616}
The two names refer to the same thing by now, so this patch is
entirely mechanical.
Bug: v8:3770
Change-Id: Ia360c06c89af6b3da27fd21bbcaeb2bdaa28ce22
Reviewed-on: https://chromium-review.googlesource.com/c/1397705
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58615}
|argc| parameter of JSEntry is passed as int from C++ code, and loaded
into a register on the asm code. As int is 32 bit, and registers are
64 bit on 64 bit platforms, upper 32 bits of the loaded value may be
contaminated by a random value if it's passed as a stack parameter.
For now, |argc| is passed as a register parameter on all platforms, and
the upper 32 bits of |argc| is filled by zero, fortunately. However, if
we shuffle the order of parameters, |argc| can be passed as a stack
parameter and its value may be broken.
Specifically on x64 Windows, the first 4 parameters are passed as
register parameters and the rest are stack parameters. As |argc| is the
4th parameter, if we prepend another parameter and shift |argc| to
the 5th parameter, |argc| will become a stack parameter and its load
to 64 bit register breaks the value.
This CL converts the type of the |argc| parameter to intptr_t, so that
it's safe to load from stack to full width registers.
Bug: v8:8124
Change-Id: Ie7407cf5e6252ed7323a9c42389db387b0064673
Reviewed-on: https://chromium-review.googlesource.com/c/1400326
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58614}
This is a reland of part of
https://chromium-review.googlesource.com/c/v8/v8/+/1397664.
It drops the explicit fni_.Infer() call after parsing arrow functions. We'll
want to avoid inferring if the arrow function is an argument to a function
call.
It also avoids adding the single argument of "name => " to the inferred name.
Bug: chromium:916975
Change-Id: I96a934408113483d73eba14073fe21e8cfe2ada6
Reviewed-on: https://chromium-review.googlesource.com/c/1397665
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58613}
The callback to AsyncStreamingProcessor::OnFinishedStream would
call into v8 internals without restoring the current context if
the processed module had no code. Instead, now always restore the
context before doing any finishing work.
Bug: chromium:915493
Change-Id: Ib779df81301ad1e3597515a4173c9a57efc593ac
Reviewed-on: https://chromium-review.googlesource.com/c/1397672
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58612}
We currently hold the register list for {move_src_regs_} in the
{StackTransferRecipe} class, and only compute src use counts for
executing the moves. Since the use counts and the register list are
redundant, just compute the use counts right away, and get rid of the
register list.
This saves one iteration of the register list in {ExecuteMoves}.
R=ahaas@chromium.org
Bug: v8:6600, v8:8423
Change-Id: I832fb0d1c1d3afe536289162a81a49b73313e7f4
Reviewed-on: https://chromium-review.googlesource.com/c/1397670
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58611}
noexcept keyword needs to be consistent between the declaration and
implementation in C++17.
Bug: v8:8616, chromium:752720
Change-Id: Iff4022c8c4b861ebdbe8e08995af1bc4da866dae
Reviewed-on: https://chromium-review.googlesource.com/c/1396459
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58609}
Fix WebAssembly's global/constructor js-api. Globals with a value
of i64 is now valid even if Wasm BigInt feature isn't activated.
Bug: v8:8319
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Change-Id: Ia41ad69efa5253064ecdb8f59b149393cd672b68
Reviewed-on: https://chromium-review.googlesource.com/c/1382747
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58603}
This patch sets the name slot of the private name symbols for
private fields and display the names in error messages of invalid
private field accesses.
TBR: adamk@chromium.org
Bug: v8:8144
Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76
Reviewed-on: https://chromium-review.googlesource.com/c/1374332
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#58601}
This queue is used for transferring tick samples between the foreground
thread which creates them and the background thread which processes
them.
I've tested this on the node server example that we are using to
measure memory use and found that we never fill the queue at this size.
The load factor of the queue is basically a measure of how fast the
producer pushes to it and how fast the consumer processes samples from
it. To load test the configuration a bit I reduced the sampling
interval from 1000us (1000 samples/sec) to 50us (20,000 samples/sec).
At this rate we still only use 196/251 available slots in the queue at
peak load (measurement taken by keeping a running max of #slots used,
taken at StartEnqueue()).
The default sampling interval is 1000us. 512 KiB ought be enough for
anybody!
Bug: v8:7719
Change-Id: I93cc1119d3549a319d2db8b831781712bfb88613
Reviewed-on: https://chromium-review.googlesource.com/c/1397704
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58600}
R=joransiu@ca.ibm.com
Drive-by: clean up the macro on s390x since it's not used.
Change-Id: I317508c1f8a1520ee8873b4323cacd63b8a7cce2
Reviewed-on: https://chromium-review.googlesource.com/c/1398121
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#58599}
PPC/S390 has been droped 32/31-bit support.
So adjust the padding size for 64-bit only.
Change-Id: I3533ef4a90bee0b1e6f49aeb61498ce3054e85e7
Reviewed-on: https://chromium-review.googlesource.com/c/1397866
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#58598}
When the InstructionSelector doesn't have a valid Isolate, it should
avoid using it to look up ExternalReferences. Fortunately, this is
easy, because the result is only used for a comparison, which in case
of invalid Isolate would always fail anyway.
Bug: v8:3770
Change-Id: Ie3d65235a22021b05cf0274bf27d91bb7af21023
Reviewed-on: https://chromium-review.googlesource.com/c/1397702
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58597}
Port ccc068d5fd
Original Commit Message:
This CL does two things:
1. It introduces Call/JumpCodeObject as the bottleneck for all calls
to non-heap-constant Code objects; and
2. it dispatches directly to the off-heap entry point for all embedded
code.
Codegen at runtime remains unchanged to preserve the shorter,
branch-less calling sequence.
R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I282a5711fdd481a1fde3569e72f0a6141ebcdf2a
Reviewed-on: https://chromium-review.googlesource.com/c/1396501
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58596}
- Directly use VisitFunctionLiteral where possible
- Take shortcut for StringLiterals in BuildLoadPropertyKey
Change-Id: Ib5c3de3d2bdd354acbfeb607415854ba90622e89
Reviewed-on: https://chromium-review.googlesource.com/c/1382750
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58595}
Use the new macro to define lazily initialized leaky singletons. Avoid
the clumsy LazyInstance, which we can hopefully remove soon.
R=mlippautz@chromium.org
Bug: v8:8600
Change-Id: Ib4d23f275c7ff5ca71fa9b47345284935330ead7
Reviewed-on: https://chromium-review.googlesource.com/c/1397711
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58594}
We plan to store additional information that is not related to scopes.
The new name will reflect this fact better.
Change-Id: I4ddb1017bc255e6ad271e4448848ed630f367d5b
Reviewed-on: https://chromium-review.googlesource.com/c/1388538
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58591}
We currently iterate the list of unexecuted register moves repeatedly,
always executing the moves whose destination register is not being used
as source register any more. This can lead to quadratic execution times
if only a small number of moves is processed in every iteration.
This CL refactors this such that we iterate the moves at most three
times: Once for executing moves which can be executed right away (fast
path) and for computing the source register use counts. A second time
to execute all remaining non-cyclic moves, and a third time to execute
cyclic moves.
During the second and third iteration, whenever we decrement the source
register use count, we check whether it drops to zero and execute the
respective move right away.
R=ahaas@chromium.org
Bug: v8:6600, v8:8423
Change-Id: I503328f5ae5f0208e35d53c71b4c289d75799892
Reviewed-on: https://chromium-review.googlesource.com/c/1397703
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58588}
Stack transfers consist of a number of register moves plus a number of
register loads. We currently store both in separate vectors. This CL
changes that to be stored in arrays indexed by the destination register
(such that it behaves like a map). This avoids any dynamically growing
structures.
Measured locally, this speeds up stack transfer processing by ~10%,
which translates to ~0.5% of overall Liftoff compilation time.
R=ahaas@chromium.org
Bug: v8:6600, v8:8423
Change-Id: Id532960dcc12f228507ed75e392ad4c57710593f
Reviewed-on: https://chromium-review.googlesource.com/c/1396278
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58587}
The AsmType class uses a design similar to the old Object* model, where
arbitrary values (including 0) are reinterpret_cast to pointers. This
yields the following UBSan error, among others:
src/asmjs/asm-parser.cc:2000:51: runtime error: member call on null
pointer of type 'v8::internal::wasm::AsmType'
This patch does the smallest possible fix by turning the affected methods
into static functions. Longer-term, we should consider switching the
overall class design to a "struct wrapping an Address" model like the new
Object definition, which is a bit non-trivial because some AsmType types
are ZoneObject subclasses.
Bug: v8:3770
Change-Id: Ie2a7cdc9eab32c4c469d699212c84b0419480b4f
Reviewed-on: https://chromium-review.googlesource.com/c/1397663
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58586}
The C++ spec does not guarantee IEEE-754 behavior for doubles, in
particular it says that dividing by zero is undefined behavior,
and UBSan complains about it when it happens.
Bug: v8:3770
Change-Id: I79e52c0e11ebfb581191f6f1c3ff95eb747dd97f
Reviewed-on: https://chromium-review.googlesource.com/c/1391751
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58580}
- Removes the last `CORE` JS native script: `prologue.js`.
- Removes build step and bootstrapping associated with building/loading `CORE` JS natives.
- Removes `natives_utils_object` from context.
- Deprecates `--expose-natives-as` flag.
- Ports extra utils functions to C++ (`uncurryThis`) or Torque
(`createPrivateSymbol`, `markPromiseAsHandled`, and `promiseState`).
- Move extra utils constants initialization into bootstrapper
(`kPROMISE_PENDING`, `kPROMISE_FULFILLED`, `kPROMISE_REJECTED`).
- Removes unused extra utils functions `log` and `logStackTrace`.
Drive-by: Added test coverage for Array#includes being an unscopeable.
Bug: v8:7624
Change-Id: I5d983f8d11b76cb4dd3c2c67592ce1dc88364cd9
Reviewed-on: https://chromium-review.googlesource.com/c/1381672
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#58577}
This simplifies NextArrowFunctionInfo, allows us to Scope::Snapshot::Reparent
directly rather than moving it, and allows us to skip reparenting in the simple
parameter arrow function cases.
This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/1397664,
simply splitting out the arrow-function-name-inferring part.
Change-Id: I640d911a9607edc3bbb0e5ff3bf992094e4159e4
Reviewed-on: https://chromium-review.googlesource.com/c/1397701
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58570}
This is a fully semantically preserving CL, it just moves code around a
bit to make the follow-up CL easier to review.
R=ahaas@chromium.org
Bug: v8:6600, v8:8423
Change-Id: I0de80b18faa3ae570894cbd8073c495a5731d255
Reviewed-on: https://chromium-review.googlesource.com/c/1396096
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58569}
Real world websites don't benifit from aborting preparsing to eagerly compile
long trivial functions, and it adds unecessary complexity to the parser and
doesn't work well with bytecode flushing, so we remove it.
Perf Sheriffs: this is expected to regress the MandreelLatency benchmark on
Octane.
BUG=v8:8395
Change-Id: Ia60cd67d4dd100376d2a366939a1d2a97cbc2b0d
Reviewed-on: https://chromium-review.googlesource.com/c/1394297
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58568}
This is a reland of 2963f1b2e3
Original change's description:
> [parser] Simplify ParseFunctionBody
>
> - Merge is_simple branches at the top
> - Remove block around inner_body parsing. Always merge fully at the end.
> - Remove conditional inner block adding to outer body. Simply add it to the
> inner body making merge push it to the parent.
>
> Change-Id: I1f062918a7abac354b949136463517bd0440984f
> Reviewed-on: https://chromium-review.googlesource.com/c/1386111
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58390}
Change-Id: I145f0cb1eda1dca4dd047b55e54b2b1bb704ecf8
Reviewed-on: https://chromium-review.googlesource.com/c/1397662
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58567}
This reverts commit dcd75706c0.
Reason for revert: Breaks layout tests, blocks roll, see
https://crrev.com/c/1396602; there are wasm CLs in this range too,
but this CL looks like the most likely culprit.
Original change's description:
> Reland: [Compiler] Ensure unoptimized code generation is context independent.
>
> Now that Asm.js code is also context independent, move code to ensure context independence
> from BytecodeGenerator to FinalizeUnoptimizedCode.
>
> Reland of CL: https://chromium-review.googlesource.com/c/v8/v8/+/1349236
>
> Change-Id: I718090850870c61733e0719d4091ec60bc080ebb
> Reviewed-on: https://chromium-review.googlesource.com/c/1396201
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58558}
TBR=rmcilroy@chromium.org,delphick@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I5f547319f31f87777165361747dd42d223fc0b0e
Reviewed-on: https://chromium-review.googlesource.com/c/1396427
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58564}
We cannot take the fast-path if the user messed with the Symbol.species
property on the Promise.prototype, as that makes the internal promises
observable.
Bug: chromium:917076
Change-Id: I928e0bd17836ca78cf88591610526aa7bc1d293c
Reviewed-on: https://chromium-review.googlesource.com/c/1396426
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58563}
Now that Asm.js code is also context independent, move code to ensure context independence
from BytecodeGenerator to FinalizeUnoptimizedCode.
Reland of CL: https://chromium-review.googlesource.com/c/v8/v8/+/1349236
Change-Id: I718090850870c61733e0719d4091ec60bc080ebb
Reviewed-on: https://chromium-review.googlesource.com/c/1396201
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58558}
With this CL it is possible to import any JavaScript object as an anyref
global. The exception is WasmGlobalObject, which cannot hold anyref
globals yet.
R=clemensh@chromium.org
Bug: v8:7581
Change-Id: I5b0fc686a4ec5c579d1d635b53be5ccdf0a78f27
Reviewed-on: https://chromium-review.googlesource.com/c/1382452
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58557}
This reverts commit 26a78061af.
Reason for revert: Not all fuzzers support custom segfault handlers yet, see https://crbug.com/918949
Original change's description:
> Remove trap handler fallback for sanitizers
>
> Since https://crrev.com/c/1335572, our sanitizers allow to set custom
> segfault handlers. Thus remove special code that was added to handle
> sanitizers that prevent installation of segfault handlers. Instead,
> CHECK that the signal handler was installed correctly.
>
> R=ahaas@chromium.org, mseaborn@chromium.org, mark@chromium.org
>
> Bug: chromium:830894
> Change-Id: I3bd66e33efdceb3e8469f3f4a09fbde90cb3d7ec
> Reviewed-on: https://chromium-review.googlesource.com/c/1392199
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58513}
TBR=mseaborn@chromium.org,ahaas@chromium.org,mark@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:830894, chromium:918949
Change-Id: Ide545860cf7729139ac50c0dd2e85facca49b0b1
Reviewed-on: https://chromium-review.googlesource.com/c/1396277
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58556}
