A testing method was missing a code ref scope, making fuzzers fail.
R=mstarzinger@chromium.org
Bug: chromium:952759
Change-Id: Ib9d485fad85f66ca358a769a4e52777f68367991
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571605
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60909}
Using the Isolate's allocator when creating the WasmModule can lead to
use-after-free situations when the NativeModule is shared across
Isolates.
R=mstarzinger@chromium.org
Bug: v8:9079
Change-Id: I5a564852179cc5b9d4cbad2a002d3b6e14b01968
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550404
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60605}
This adds preliminary support for handling the "br_on_exn" opcode in the
interpreter. It also makes "catch" and "rethrow" use a proper exception
reference instead of a dummy value.
To that end this also adds {Handle<>} as a new kind of {WasmValue} which
is intended to pass reference values (e.g. "anyref" or "except_ref") to
the runtime system. Therefore lifetime of such a {WasmValue} is directly
coupled to any surrounding {HandleScope}.
For now we just store {Handle<>} directly on the simulated operand stack
of the interpreter. This is of course bogus, since the surrounding scope
does not outlive the interpreter activation. Decoupling the lifetime of
the operand stack from a {HandleScope} will be done in a follow-up CL.
As a drive-by this change also implements support for the "ref_null" and
the "ref_is_null" opcodes as a proof-of-concept that the new {WasmValue}
is also applicable to the "anyref" reference type.
R=clemensh@chromium.org
TEST=cctest/test-run-wasm-interpreter/ReferenceTypeLocals
BUG=v8:8091,v8:7581
Change-Id: I2307e0689a19c4aab1d67f1ba6742cb3cc31aa3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550299
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60598}
The tiers are now consistently referred to as baselin and top tier.
Bug: v8:9003
Change-Id: I74ad1867aca63bee9eb83b7f0f9fbaf2b1523dcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547667
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60591}
This is just one small unit test for now. As we expect to adapt the
encoding this is more of an exercise than exhaustive testing.
Bug: v8:9003
Change-Id: I8f59043c3f7acbb6169254ec6d6ae13251d1054f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526010
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60358}
Drive-by: Refactor FlushInstructionCache to its own header. This removes
dependencies of objects.cc and code.cc
Bug: v8:8562
Change-Id: If23f3b9d4f2068e08c61c0f4b070ecfe1b9a6cc0
Reviewed-on: https://chromium-review.googlesource.com/c/1456081
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59435}
The build config inherited from Chromium only enables a subset
of the checks that UBSan supports. We want them all, so this
patch overrides what "is_ubsan" means for V8.
Bug: v8:3770
Change-Id: I1d0a7d994279272f13ff1d4ac9ed235fcbfc0951
Reviewed-on: https://chromium-review.googlesource.com/c/1443502
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59222}
This adds preliminary support for exception handling to the interpreter.
Note that due to missing reference type support, the exception object is
not yet correctly put onto the operand stack. Also exceptions raised by
call operations are not handled properly yet.
R=clemensh@chromium.org
TEST=cctest/test-run-wasm-exceptions
BUG=v8:8091
Change-Id: Ie68ca9448c7beafe8967dff5bb5de6642edcc9e4
Reviewed-on: https://chromium-review.googlesource.com/c/1436017
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59131}
Refactor the AllocateAssemblerBuffer helper for the new Assembler API.
This is the only non-mechanical part, all other callsites that create
Assembler instances can be trivially changed to the new API. This will
be done in a separate CL.
R=mstarzinger@chromium.org
Bug: v8:8689, v8:8562
Change-Id: I6c150748eeea778d9b70f41fd66fbb1221035a1b
Reviewed-on: https://chromium-review.googlesource.com/c/1415490
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58881}
We often use ResultBase or VoidResult to store or pass wasm errors
(errors with locations). This CL extracts a WasmError class which can
store an error (can also be empty), and Result<T> which stores an error
or a T (exactly one of them).
R=titzer@chromium.org
Bug: v8:8689
Change-Id: I3f5203559984a0ae8757e0130a9184957fa28df5
Reviewed-on: https://chromium-review.googlesource.com/c/1409365
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58827}
The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT.
The unittests test if the trap handler only handles those traps it
is supposed to handle:
* Only handle traps when the thread-in-wasm flag is set.
* Only handle traps of the right type, i.e. memory access violations.
* Only handle traps at recorded instructions.
The tests also test the consistency of the thread-in-wasm flag. I made
one change in the trap handler where that consistency could be
violated.
All tests are executed with the default trap handler provided by V8,
and with the trap handler callback installed in a test signal/exception
handler.
Patchset 1 is the original CL.
R=mstarzinger@chromium.org
Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79
Reviewed-on: https://chromium-review.googlesource.com/c/1351024
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57947}
This unifies the order of i-cache flushing and permission changing
throughout V8. According to cctest/test-icache flushing after the
permission change is not robust on some ARM32 and ARM64 devices.
There have been observed failures of {TestFlushICacheOfExecutable} on
some devices. So far there haven't been any observed failures of the
corresponding {TestFlushICacheOfWritable} test.
Also the order of flushing before the permission change is the natural
order in which the GC currently performs operations. Until we see
concrete data substantiating the opposite, the following is the
supported and intended order throughout V8:
exec -> perm(RW) -> patch -> flush -> perm(RX) -> exec
This CL tries to establish said order throughout the codebase.
R=ulan@chromium.org
TEST=cctest/test-icache
BUG=v8:8507,chromium:845877
Change-Id: Ic945082e643aa2d142d222a7913a99816aff4644
Reviewed-on: https://chromium-review.googlesource.com/c/1351025
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57869}
This reverts commit 4644b32e02.
Reason for revert: Link errors on win64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20debug/25950
Original change's description:
> [wasm] Add more unit tests for trap handler
>
> The unittests test if the trap handler only handles those traps it
> is supposed to handle:
> * Only handle traps when the thread-in-wasm flag is set.
> * Only handle traps of the right type, i.e. memory access violations.
> * Only handle traps at recorded instructions.
>
> The tests also test the consistency of the thread-in-wasm flag. I made
> one change in the trap handler where that consistency could be
> violated.
>
> All tests are executed with the default trap handler provided by V8,
> and with the trap handler callback installed in a test signal/exception
> handler.
>
> Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
> Reviewed-on: https://chromium-review.googlesource.com/c/1340246
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57858}
TBR=mstarzinger@chromium.org,ahaas@chromium.org,mark@chromium.org
Change-Id: Iac2f20c73744226885ea1810813863a21c5faf8c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1351021
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57861}
The unittests test if the trap handler only handles those traps it
is supposed to handle:
* Only handle traps when the thread-in-wasm flag is set.
* Only handle traps of the right type, i.e. memory access violations.
* Only handle traps at recorded instructions.
The tests also test the consistency of the thread-in-wasm flag. I made
one change in the trap handler where that consistency could be
violated.
All tests are executed with the default trap handler provided by V8,
and with the trap handler callback installed in a test signal/exception
handler.
Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
Reviewed-on: https://chromium-review.googlesource.com/c/1340246
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57858}
Moves allocation of the WasmModuleObject for asm.js code out of SyncCompileTranslatedAsmJS
since that is called when we are compiling the native context independent SharedFunctionInfo
and the WasmModuleObject requires a native context. Instead save the members required to
create the object in the AsmWasmData and create it during module instantiation. Note:
since the Wasm module is an implementation detail for asm_wasm code and isn't exposed,
this doeesn't have semantic change for asm.js code.
As part of this change, the AsmWasmData is changed from a FixedArray to a dedicated
struct. Some logic is also moved from module-compiler to wasm-engine to make the
seperation between Wasm SyncCompile and AsmJS SyncCompile more clear.
BUG=chromium:900535,v8:8395
Change-Id: Ia48469c095b0688f210aa86e7430c9ab4ea4b26b
Reviewed-on: https://chromium-review.googlesource.com/c/1345509
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57704}
Instead of returning 0xDEADBEEF, return a struct with proper
information. Otherwise a function returning 0xDEADBEEF would be
misidentified as trapping in the interpreter.
R=ahaas@chromium.org
Bug: chromium:906997
Change-Id: I92fc3a9972d76d2f8a5b313bf6be6eb027cfc1e9
Reviewed-on: https://chromium-review.googlesource.com/c/1344111
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57658}
These instructions aren't implemented yet in TF or in Liftoff, but they
are properly decoded.
The table instructions (i.e. `table.{init,drop,copy}`) are validated,
since the table and element sections occur before the code section. The
memory instructions (i.e. `memory.{init,drop,copy,fill}`) are not
validated because the data section occurs after the code section, so it
can't be verified in one pass (without throwing a validation error
later).
There is currently a discussion about whether to add a new section
(similar to `func`) that predefines the number of expected data
segments. If we add this, then we can validate in one pass. For now,
we'll leave it unimplemented.
Bug: v8:7747
Change-Id: I839edf51721105a47a1fa8dd5e5e1bd855e72447
Reviewed-on: https://chromium-review.googlesource.com/c/1339241
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57622}
See the WebAssembly bulk memory proposal here:
https://github.com/WebAssembly/bulk-memory-operations
This initial CL adds a wasm experimental flag:
`--experimental-wasm-bulk-memory`, and also parsing of passive segments.
A passive segment is one that is not copied into the table/memory on
instantiation, but instead later via the `{table,memory}.init`
instructions.
The binary format of passive data segments is unlikely to change, but
the format for passive element segments may change (see
https://github.com/WebAssembly/bulk-memory-operations/pull/39).
Bug: v8:7747
Change-Id: I2a7fb9bc7648a722a8c4aab4185c68d3d0843858
Reviewed-on: https://chromium-review.googlesource.com/c/1330015
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57451}
The "grow_memory" opcode was renamed to "memory.grow", and the spec
repo was updated to use kExprMemoryGrow internally instead of
kExprGrowMemory (https://github.com/WebAssembly/spec/pull/720).
This CL does the same change for v8.
Drive-by: Rename "current_size" to "memory.size", and a minor cleanup
in wasm-graph-builder.js to bring it in line with the version in the
js-api tests in the spec repo.
R=titzer@chromium.org
Change-Id: If525dba898b2c248890a616d3392c22b45f698ef
Reviewed-on: https://chromium-review.googlesource.com/c/1302057
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57089}
Previously, this was just a field on the WasmResult, which is not
allowed according to the style guide.
A special r-value accessor for the value is needed for the cases where
the contained type is not copyable, e.g. unique_ptr.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: Ia3c14c4c62c3c2e07f1dc4594f1bc9d1da88f91e
Reviewed-on: https://chromium-review.googlesource.com/c/1290974
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56823}
Compute the length of more fields automatically, in particular names.
This is the fifth CL in a series to improve our module decoder tests and
make them more readable.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: I1bd27f45380d82af2d7319f15ac7e37d5b9e4081
Reviewed-on: https://chromium-review.googlesource.com/c/1283077
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56721}
Function declarations reference a previously defined or imported
signature. Make this visible when declaring empty functions.
Also rename IMPORT_SIG_INDEX to SIG_INDEX since it can also reference a
locally defined signature.
This is the third CL in a series to improve our module decoder tests and
make them more readable.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: Ibfd9ea39ea35bacdb453602f8985fb3306455de4
Reviewed-on: https://chromium-review.googlesource.com/c/1282958
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56714}
We were re-definining the FunctionSig typedef in several places. This
CL moves it to value-type.h, since it's a signature over ValueType.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: Id5e8a55c7e0f98d61235e32a5e6cd12e04d26947
Reviewed-on: https://chromium-review.googlesource.com/c/1278387
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56597}
... like AllocatePage[s](), FreePages() and SetPermissions().
This CL also changes base::PageAllocator to cache AllocatePageSize and CommitPageSize
values returned by the OS.
This is a necessary cleanup before introducing BoundedPageAllocator.
Bug: v8:8096
Change-Id: Ifb7cdd2caa6a1b029ce0fca6545c61df9d281be2
Reviewed-on: https://chromium-review.googlesource.com/1209343
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55690}
This adds the ability to add exception types to the export section of a
module and reference them via the local exception index. Currently the
export object then just contains the local index as a number, which is
only temporary until we have proper export wrappers for exceptions.
Also note that this tightens the restriction for the modules exception
section to be located in between the import and the export section.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-export
BUG=v8:8091
Change-Id: Ie26081c3f94e71cb576057db7e45ec5bd0e112f9
Reviewed-on: https://chromium-review.googlesource.com/1206873
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55679}
This CL introduces a set of configuration options implemented as
a struct of booleans that together comprise the set of enabled
or detected features. The configuration options replace command-line
flags that were checked deep in the implementation. As such, it is
necessary to plumb them through multiple levels of abstraction.
R=ahaas@chromium.orgCC=mstarzinger@chromium.org
BUG=chromium:868844
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I1b82f5826e4fd263f68e8cafcd923bac5818a637
Reviewed-on: https://chromium-review.googlesource.com/1163670
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55018}
This adds initial support for concurrently patching jump table slots. It
is needed once different Isolates share code (for the --wasm-shared-code
feature). We need to ensure that instructions holding the target address
within a jump table slot do not cross cache-line boundaries. To do this,
the jump table has been split into consecutive pages.
Note that this also adds a stress test for multiple threads hammering at
a single slot concurrently. The test is currently limited to the ia32
and the x64 architecture, but will be extended to cover others. The test
reliably triggers tearing of the target address on almost every run of
the test and hence serves to prevent regressions.
R=clemensh@chromium.org
TEST=cctest/test-jump-table-assembler
BUG=v8:8018
Change-Id: Ife56bbb61ffcae5d8906ca7b8c604b195603707c
Reviewed-on: https://chromium-review.googlesource.com/1163664
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54942}
The tests were not flushing the i-cache before calling the generated
code. Use Factory::NewCode to make sure that the i-cache is flushed
instead.
Bug: v8:7977
Change-Id: I9c7c6f0d0e31700634e50279e75858a5d74603d8
Reviewed-on: https://chromium-review.googlesource.com/1150165
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#54711}
This is a reland of a462a7854a
Original change's description:
> [turboassembler] Introduce hard-abort mode
>
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
>
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
>
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
>
> R=mstarzinger@chromium.org
>
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}
Bug: chromium:863799
Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
Reviewed-on: https://chromium-review.googlesource.com/1146100
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54656}
This reverts commit a462a7854a.
Reason for revert: Breaks a TurboAssembler test:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726
Original change's description:
> [turboassembler] Introduce hard-abort mode
>
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
>
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
>
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
>
> R=mstarzinger@chromium.org
>
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:863799
Reviewed-on: https://chromium-review.googlesource.com/1145431
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54597}
For checks and assertions (mostly for debug code, like stack alignment
or zero extension), we had two modes: Emit a call to the {Abort}
runtime function (the default), and emit a debug break (used for
testing, enabled via --trap-on-abort).
In wasm, where we cannot just call a runtime function because code must
be isolate independent, we always used the trap-on-abort behaviour.
This causes problems for our fuzzers, which do not catch SIGTRAP, and
hence do not detect debug code failures.
This CL introduces a third mode ("hard abort"), which calls a C
function via {ExternalReference}. The C function still outputs the
abort reason, but does not print the stack trace. It then aborts via
"OS::Abort", just like the runtime function.
This will allow fuzzers to detect the crash and even find a nice error
message.
Even though this looks like a lot of code churn, it is actually not.
Most added lines are new tests, and other changes are minimal.
R=mstarzinger@chromium.org
Bug: chromium:863799
Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
Reviewed-on: https://chromium-review.googlesource.com/1142163
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54592}
This removes several GetIsolate calls from Map:: methods and instead
passes the Isolate in. This is a very noisy change but mostly it is just
adding Isolate to method declarations and forwarding it on.
Bug: v8:7786
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I159505e50a9462d01066f14da0fcc29762bd5531
Reviewed-on: https://chromium-review.googlesource.com/1075267
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53826}
We currently store the {WasmModule} (generated during decoding) in a
unique_ptr and pass ownership to the {WasmModuleObject} after
compilation.
I plan to move the {Managed<NativeModule>} from {WasmCompiledModule} to
{WasmModuleObject}, which will force us to create the
{WasmModuleObject} *before* compilation, so that the {CompilationState}
is available during compilation.
This CL prepares that refactoring by storing the {WasmModule} in a
{shared_ptr} in the {AsyncCompileJob}. Note that it will eventually be
stored in a {shared_ptr} in the {Managed} anyway.
R=titzer@chromium.org
Change-Id: Iac5e3c1067af2801e938f77a455a68807801526a
Reviewed-on: https://chromium-review.googlesource.com/1104117
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53801}
This CL splits the definition of ValueType and its helper functions
into its own header file.
R=clemensh@chromium.org
Bug: v8:7570
Change-Id: I3aa776edb45839d7d38836e131df45732c685310
Reviewed-on: https://chromium-review.googlesource.com/1021810
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52758}
This change makes lifetime management of WasmCode much simpler.
By using the WasmInstanceObject as the context for WASM code execution,
including the pointer to the memory base and indirect function tables,
this keeps the instance alive when WASM code is on the stack, since
the instance object is passed as a parameter and spilled onto the stack.
This is in preparation of sharing the code between instances and
isolates.
Bug: v8:7424
R=mstarzinger@chromium.org
Change-Id: Ia35a3ce91a8f6135767fa764e185cde8bbc889f4
Reviewed-on: https://chromium-review.googlesource.com/997932
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52436}
Add support for decoding anyref globals, and some drive-by cleanups.
R=titzer@chromium.org
Bug: v8:7581
Change-Id: I3527f996a3fa1a890918a5924e951fbafa394cf2
Reviewed-on: https://chromium-review.googlesource.com/997655
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52391}
This reverts commit 57bf0bfefb.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [wasm] Merge the WasmContext into WasmInstanceObject
>
> This change makes lifetime management of WasmCode much simpler.
> By using the WasmInstanceObject as the context for WASM code execution,
> including the pointer to the memory base and indirect function tables,
> this keeps the instance alive when WASM code is on the stack, since
> the instance object is passed as a parameter and spilled onto the stack.
> This is in preparation of sharing the code between instances and
> isolates.
>
> Bug: v8:7424
>
> Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
> Reviewed-on: https://chromium-review.googlesource.com/958520
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52361}
TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7424
Reviewed-on: https://chromium-review.googlesource.com/995418
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52364}
This change makes lifetime management of WasmCode much simpler.
By using the WasmInstanceObject as the context for WASM code execution,
including the pointer to the memory base and indirect function tables,
this keeps the instance alive when WASM code is on the stack, since
the instance object is passed as a parameter and spilled onto the stack.
This is in preparation of sharing the code between instances and
isolates.
Bug: v8:7424
Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
Reviewed-on: https://chromium-review.googlesource.com/958520
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52361}
Adds the remaining saturating float to int conversion opcodes.
Bug: v8:7226
Change-Id: If84e564a7816eb4aedbc336f5c2e614da22bb10a
Reviewed-on: https://chromium-review.googlesource.com/905472
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51157}
Implements the saturating opcode i64.trunc_s:sat/f32.
Also does some refactoring of the i32 saturating opcodes use a simplier
solution (calling a single method to handle all i32 values).
Also refactors code so that the remaining i64 saturating conversions
should be easy to add to the wasm compiler.
Bug: v8:7226
Change-Id: I031aca1e059b4baa989a56ecbc16941f591ff9b3
Reviewed-on: https://chromium-review.googlesource.com/887333
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51001}
This is a further step to separate the implementation of the JavaScript
API from the internals of the WASM implementation. Now, wasm-js.cc
only needs to interact with the WASM engine and is (almost) independent
of module-decoder.h and module-compiler.h.
Also, move SyncCompileAndInstantiate() into wasm-module-runner.cc.
Bug: v8:7316
R=clemensh@chromium.org, mstarzinger@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I7765af54ac16f53a5ff88c17a22c5d36bacaf926
Reviewed-on: https://chromium-review.googlesource.com/870871
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50679}
Adds I32UConvertF32, I32SConvertF64, and I32UConvertF64 instructions.
Refactors code to use templates where appropriate, and to use
previously committed template function is_inbounds() when appropriate
in tests.
Bug: v8:7226
Change-Id: I2701e5fd0b21cefa1f285677f20616cfde29ab0d
Reviewed-on: https://chromium-review.googlesource.com/862609
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50632}
This CL centralizes constants related to decoding from several places
into one place and makes it no longer necessary to include
wasm-opcodes.h for some simple constants.
R=clemensh@chromium.org
Bug:
Change-Id: I53aa81e34167df467bc7455b717bf67083033943
Reviewed-on: https://chromium-review.googlesource.com/859764
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50503}
This CL adds the i32.trunc_s:sat/f32 WASM opcode to the turbofan
compiler and interpreter (more saturating operators will be added in
later CLs).
The operatation has been added under an experimental flag.
Bug: v8:7226
Change-Id: Ia69e981ffddb2da682e53ba25f489fc9d0cd2db5
Reviewed-on: https://chromium-review.googlesource.com/834670
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50311}
This patch normalizes the casing of hexadecimal digits in escape
sequences of the form `\xNN` and integer literals of the form
`0xNNNN`.
Previously, the V8 code base used an inconsistent mixture of uppercase
and lowercase.
Google’s C++ style guide uses uppercase in its examples:
https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
Moreover, uppercase letters more clearly stand out from the lowercase
`x` (or `u`) characters at the start, as well as lowercase letters
elsewhere in strings.
BUG=v8:7109
TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
Reviewed-on: https://chromium-review.googlesource.com/804294
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49810}
Typically the interpreter returns 0xdeadbeef to indicate an exception.
However, for stack overflows a normal exception is used. The interpreter
requires an activation, however, to deal with normal exceptions. With
this CL we start an activation before we execute the fuzzer input in the
interpreter.
R=clemensh@chromium.org
Bug: chromium:781103
Change-Id: I4fc3a18bfc2076aab9ff7d2324a3311fe222954a
Reviewed-on: https://chromium-review.googlesource.com/776835
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49545}
Only change over original: Init sig_index to 0 at
function-body-decoder-impl.h:168, to make MSAN happy on error path.
R=titzer@chromium.org
Change-Id: I9ac17215360523b656b10d2466201001b65992c0
Reviewed-on: https://chromium-review.googlesource.com/712655
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48463}
Fix disassembly of atomic operations for the inspector.
BUG=v8:6842,v8:6532
Change-Id: I3701b55c28b10561d1726e2c0b9fe2e1b2c76b8e
Reviewed-on: https://chromium-review.googlesource.com/703468
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48324}
Note that this also makes it possible to move several classes
into the module-compiler.cc file and inline their implementations.
This also allows removing several uses of wasm-module.h from
other places in V8 that include wasm-objects.h.
R=yangguo@chromium.org,clemensh@chromium.org,ahaas@chromium.org
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I303ee2bb49dc53c951d377a1b65699c1e0e91da7
Reviewed-on: https://chromium-review.googlesource.com/687494
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48204}
This is a second attempt at landing CL 644866 which was reverted by
CL 667019.
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
A JS typed (uint_16) array is used to hold the thrown values. This
allows all WASM types to be stored (i32, i64, f32, and f64) as well as
be inspected in JS.
The previous CL was reverted because the WASM compiler made calls to
run time functions with tagged objects, which must not be done. To fix
this, all run time calls use the thread-level isolate to hold the
exception being processed.
Bug: v8:6577
Change-Id: I4b1ef7e2847b71a2fab8e9934a0531057db9de63
Reviewed-on: https://chromium-review.googlesource.com/677056
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48148}
This reverts commit 7b5a40222e.
Reason for revert: GC stress-test failures exposed by 7742e534a8https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15110/steps/Mjsunit/logs/exceptions
Original change's description:
> Add capability of throwing values in WASM
>
> Extends the current implementation of WASM exceptions to be able to
> throw exceptions with values (not just tags).
>
> An JS typed array (uint_16) is used to hold thrown values, so that the
> thrown values can be inspected in JS.
>
> Bug: v8:6577
> Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
> Reviewed-on: https://chromium-review.googlesource.com/633866
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48001}
TBR=bbudge@chromium.org,mtrofin@chromium.org,eholk@chromium.org,clemensh@chromium.org,kschimpf@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6577
Change-Id: I8f545183c2d2abb1bf4a0b3ee23379f3754ffd55
Reviewed-on: https://chromium-review.googlesource.com/667019
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48050}
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
An JS typed array (uint_16) is used to hold thrown values, so that the
thrown values can be inspected in JS.
Bug: v8:6577
Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
Reviewed-on: https://chromium-review.googlesource.com/633866
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48001}
In the test case the module contained a memory which got exported by the
name 'main'. The fuzzer crashed when it tried to cast the memory to a
function to execute it. This CL checks that 'main' is a function before
doint the cast.
R=clemensh@chromium.org
Bug: chromium:763349
Change-Id: I9a21413c8038a7547f8b59057afea2870b15499a
Reviewed-on: https://chromium-review.googlesource.com/659978
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47941}
Even though we were generating additional arguments with default value
in the case that the caller was not providing enough, we then passed
the original pointer, leading to potential out-of-bounds accesses.
R=ahaas@chromium.org
Bug: chromium:763294,chromium:763297
Change-Id: Id18622d0d40e0408e26a5fc6f97494b5f9e18d17
Reviewed-on: https://chromium-review.googlesource.com/657699
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47930}
The wasm-async fuzzer uses the bytes provided by the fuzzer engine
directly as wasm module bytes, compiles them with async compilation, and
then tries to execute the "main" function of the module. This "main"
can have an infinite loop which causes a timeout in the fuzzer. With
this CL the "main" function is first executed with the interpreter. If
the execution in the interpreter finishes within 16k steps, which means
that there is no infinite loop, also the compiled code is executed.
I added the raw fuzzer input as a test case because in this case I
really want to test the fuzzer and not V8.
R=clemensh@chromium.org
Bug: chromium:761784
Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162
Reviewed-on: https://chromium-review.googlesource.com/651046
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47874}
This is a pure renaming CL; no functionality changes.
R=mtrofin@chromium.org
Bug:
Change-Id: I2f8262bdb17b9256d5b66fad56a7e51063f6f0d9
Reviewed-on: https://chromium-review.googlesource.com/610007
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47282}
This is part of the effort to consolidate the ownership of
wasm instantiation/specialization parameters.
This change is focused solely on the interpreter part of that effort, to
verify we're not regressing performance in interpreter benchmarks.
There are two aspects being addressed:
- dataflow-wise, we always fetch the interpreter's memory view from the
runtime objects (i.e. WasmInstanceObject/WasmCompiledModule). This is
consistent with how other instance-specific information is obtained
(e.g. code, indirect functions).
- representation-wise, we do not reuse ModuleEnv/WasmInstance just for
the memory view, because it is surprising that other instance info isn't
accessed from there.
Bug:
Change-Id: I536fbffd8e1f142a315fa1770ba9b08319f56a8e
Reviewed-on: https://chromium-review.googlesource.com/602083
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47205}
This allows to reuse the class e.g. in the baseline compiler.
R=titzer@chromium.org
Change-Id: I7251af16e8c74f267834a9cefb676edf3c9f3a07
Reviewed-on: https://chromium-review.googlesource.com/570020
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46735}
This is a reland of 5648aad553.
Previous compile error should be fixed by disabling strict aliasing
assumptions on gyp: https://chromium-review.googlesource.com/c/571806
Original change's description:
> [wasm] Don't store global handles in the interpreter
>
> Storing global handles in the interpreter is dangerous, because the
> global handles are strong roots into the heap. The interpreter itself is
> referenced from the heap via a Managed. Hence the interpreter keeps the
> instance alive, while the instance keeps the Managed alive. So the GC
> will never collect them.
>
> This CL refactors this to only store the handle to the instance object
> while executing in the interpreter, and clearing it when returning.
> It also removes the cache of import wrappers, as it should not be
> performance critical, but keeps lots of objects alive. If it turns out
> to be performance critical, we will have to reintroduce such a cache
> stored in the WasmDebugInfo object.
>
> R=titzer@chromium.org
> CC=ahaas@chromium.org
>
> Bug: chromium:610330
> Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
> Reviewed-on: https://chromium-review.googlesource.com/567058
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46629}
TBR=titzer@chromium.org
Bug: chromium:610330
Change-Id: Ic7836b1b1a044a89f2138f0c76f92acd3a1b2f2b
Reviewed-on: https://chromium-review.googlesource.com/570578
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46679}
This reverts commit 5648aad553.
Reason for revert: Compile error on mips:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/10732
Original change's description:
> [wasm] Don't store global handles in the interpreter
>
> Storing global handles in the interpreter is dangerous, because the
> global handles are strong roots into the heap. The interpreter itself is
> referenced from the heap via a Managed. Hence the interpreter keeps the
> instance alive, while the instance keeps the Managed alive. So the GC
> will never collect them.
>
> This CL refactors this to only store the handle to the instance object
> while executing in the interpreter, and clearing it when returning.
> It also removes the cache of import wrappers, as it should not be
> performance critical, but keeps lots of objects alive. If it turns out
> to be performance critical, we will have to reintroduce such a cache
> stored in the WasmDebugInfo object.
>
> R=titzer@chromium.org
> CC=ahaas@chromium.org
>
> Bug: chromium:610330
> Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
> Reviewed-on: https://chromium-review.googlesource.com/567058
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46629}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: Ifadfb885f937f37bb3eab4732a97f20ff40c2583
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:610330
Reviewed-on: https://chromium-review.googlesource.com/569962
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46630}
Storing global handles in the interpreter is dangerous, because the
global handles are strong roots into the heap. The interpreter itself is
referenced from the heap via a Managed. Hence the interpreter keeps the
instance alive, while the instance keeps the Managed alive. So the GC
will never collect them.
This CL refactors this to only store the handle to the instance object
while executing in the interpreter, and clearing it when returning.
It also removes the cache of import wrappers, as it should not be
performance critical, but keeps lots of objects alive. If it turns out
to be performance critical, we will have to reintroduce such a cache
stored in the WasmDebugInfo object.
R=titzer@chromium.orgCC=ahaas@chromium.org
Bug: chromium:610330
Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
Reviewed-on: https://chromium-review.googlesource.com/567058
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46629}
This adds a convenience method for the common Smi to int conversion
pattern.
Bug:
Change-Id: I7d7b171c36cfec5f6d10c60f1d9c3e06e3aed0fa
Reviewed-on: https://chromium-review.googlesource.com/563205
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46516}
In our internal code, we should only use pending exceptions. They will
be converted to scheduled exceptions on the API boundary.
Hence, the ErrorThrower just sets a pending exception; it should never
have to think about scheduled exceptions. The new
ScheduledErrorThrower inherits from ErrorThrower and reschedules any
pending exceptions in its destructor (turning them into scheduled
exceptions).
In some situations, there might already be a scheduled exception, e.g.
when calling other API methods (v8::Value::Get). In this case, the
ErrorThrower should also not set another pending exception. For the
reasons mentioned above, this can only be handled in the
ScheduledErrorThrower, which is used the API methods.
This fixes one DCHECK failure and one TODO about scheduled exceptions
if no instance can be created, because the start function throws.
R=mtrofin@chromium.org, mstarzinger@chromium.org
BUG=v8:6232,chromium:736256
Change-Id: I4905be04c565df9495de18fb26adbb5c05d193d2
Reviewed-on: https://chromium-review.googlesource.com/548641
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46314}
Removes from CL https://codereview.chromium.org/2929853003 code to fix
histogram timers in class WasmCompilationUnit. This was done because
the CL was reverted due to errors caused by background compiles that
updated UMA histogram timers.
The goal of this CL is to reland the remaining portion of the reverted
CL.
Bug:v8:6361
Change-Id: Ic03ceb118734bd55c463a843521bcd5b09342afe
Reviewed-on: https://chromium-review.googlesource.com/550196
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@google.com>
Cr-Commit-Position: refs/heads/master@{#46268}
This is a fix to https://codereview.chromium.org/2929853003 that got
reverted. The DCHECK checked to see that it was not in a background
thread. While this is a property we want for v8, it is also used
by blink, and blink violates this property.
Therefore, this CL removes the DCHECK for now.
BUG=v8:6361
Review-Url: https://codereview.chromium.org/2961443002
Cr-Commit-Position: refs/heads/master@{#46190}
HistoryTimer's can't run in the background because they use a timer
with a simple api of Start() and Stop(). This CL fixes this problem
by building a base class TimedHistogram that doesn't have a timer.
The class HistoryTimer is modified to use this base class so that
uses that run on the foreground thread do not need to be modified.
It also adds a new class TimedHistogramScope that defines the timer
in this class. This allows the corresopnding TimedHistogram class to
be type safe.
BUG=v8:6361
Review-Url: https://codereview.chromium.org/2929853003
Cr-Commit-Position: refs/heads/master@{#46150}
The fuzzer has already been removed from chromium. In addition I removed
code which was only used by this fuzzer.
BUG=chromium:734550
R=clemensh@chromium.orgCC=mstarzinger@chromium.org
Change-Id: I2ff4614e4d64131412ead759318e5c38e38f5d3d
Reviewed-on: https://chromium-review.googlesource.com/542816
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46078}
The EnableFlagScope is useful also for non-boolean flags. With the
template we can use if for example in the wasm fuzzers to reduce the
maximum memory size of a wasm module.
In addition I put the EnableFlagScope into the v8::internal namespace,
and I fixed a small typo.
BUG=v8:6474
R=clemensh@chromium.org
Change-Id: Iae5d5c058c334cd0f9e09d20adfd229fc2d6c585
Reviewed-on: https://chromium-review.googlesource.com/531005
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45862}
This is a testing-only function, which is semantically equivalent to a
SyncCompile followed by SyncInstantiate.
We add a new SyncCompileAndInstantiate function to do those two steps
in one go, and use this method instead.
For AsmJs modules, a new testing function CompileAndRunAsmWasmModule is
introduced.
This is part of our effort to reduce the number of special paths for
testing. It is connected with
https://chromium-review.googlesource.com/529210, but should not
conflict with it.
After landing both CLs, we can later also get rid of
InstantiateModuleForTesting.
R=ahaas@chromium.org, mtrofin@chromium.org
BUG=v8:6474
Change-Id: I7891e968370d5eb68803076ce2639c65a2799dcc
Reviewed-on: https://chromium-review.googlesource.com/529844
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45852}
This CL removes unnecessary code duplication in the fuzzer code. Instead
of having special testing functions to compile and instantiate a
WebAssembly module, we now just call SyncCompile and SyncInstantiate.
This also fixed a problem when the fuzzer generated a GrowMemory
instruction.
BUG=v8:6474
R=clemensh@chromium.org
Change-Id: I5f2f23349b5866ea67be20a0826271791e1a013e
Reviewed-on: https://chromium-review.googlesource.com/529210
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45851}
This CL removes most occurences of "WASM" from outputs and comments in
the code. They are replaced either by "WebAssembly" or (especially in
comments) "wasm". These are the spellings officially proposed on
http://webassembly.org/.
R=ahaas@chromium.org
BUG=v8:6474
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id39fa5e25591678263745a4eab266db546e65983
Reviewed-on: https://chromium-review.googlesource.com/529085
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45824}
Most prototype implementations are not fully supported in the
interpreter. This is the case at least for exception handling, simd, and
atomics. Any function can be redirected to the interpreter though,
either by passing --wasm-interpret-all, or by dynamically redirecting to
the interpreter for debugging.
Making the flags experimental keeps the fuzzer from playing around with
these flags.
Drive-by: Refactor tests which explicitly set the prototype flag to use
a new scope for that.
R=ahaas@chromium.org
BUG=chromium:727584
Change-Id: I67da79f579f1ac93c67189afef40c6524bdd4430
Reviewed-on: https://chromium-review.googlesource.com/519402
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45639}
Make ModuleResult and FunctionResult return Result<std::unique_ptr<X>>.
This makes memory ownership and transfer of ownership more clear and
avoids a lot of manual releases of the referenced native heap object.
R=ahaas@chromium.org
Change-Id: I7a3f5bd7761b6ae1ebdc7d17ff1b96a8df599871
Reviewed-on: https://chromium-review.googlesource.com/498352
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45160}
This avoids generating redundant code for different template
instantiations.
I also introduce getters instead of accessing the fields directly.
R=ahaas@chromium.org
BUG=v8:6325
Change-Id: I3e0eca9ef6a01e0a3ebb73f4f357bcb59e120f43
Reviewed-on: https://chromium-review.googlesource.com/490166
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44976}
The only users of the LoadStoreOpcodeOf function were a number of
macros in wasm-macro-gen.h, and three test functions using it directly.
This CL refactors those functions to also use the macros.
In one case, this requires storing the value in a local variable first.
R=ahaas@chromium.org
Change-Id: Ia2fbf67a3831fafc9345e155eb240cf1bf6feb5d
Reviewed-on: https://chromium-review.googlesource.com/486842
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44885}
This header file is only used from tests.
Also, move the LoadStoreOpcodeOf method (only used in tests) from
wasm-opcodes.h to wasm-macro-gen.h.
R=ahaas@chromium.org
Change-Id: I8d4691be494b5c1fbe3084441329850930bad647
Reviewed-on: https://chromium-review.googlesource.com/486861
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44845}
- Store std::string instead of std::unique_ptr<char[]> for the error
message.
- Remove ErrorCode, which was just kSuccess and kError anyway. Error is
now detected on whether error_msg_ is empty or not.
- Refactor constructors for perfect forwarding; this will allow us to
implement Result<std::unique_ptr<X*>>.
- Refactor Decoder::toResult for perfect forwarding.
- Remove output operators (operator<<) for Result; it was only used in
the error case anyway. Print error message directly instead.
The operator was problematic since it assumed the existence of an
output operator for every T which is used in Result<T>.
- Remove ModuleError and FunctionError, introduce general static
Result<T>::Error method instead.
R=ahaas@chromium.org
Change-Id: I1e0f602a61ee9780fee2a3ed33147d431fb092ba
Reviewed-on: https://chromium-review.googlesource.com/472748
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44518}
To avoid running infinitely or hitting the stack size limit, bound the
number of steps to execute in the interpreter to 16k.
R=ahaas@chromium.org
BUG=chromium:708457
Change-Id: Ib101bbbc06627641dae2fd1cd1a8d950aa504eaf
Reviewed-on: https://chromium-review.googlesource.com/469609
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44446}
This CL adds support for indirect function calls to the interpreter. It
can indirectly call other wasm function in the same instance, which are
then executed in the interpreter, or call imported functions.
Implementing this required some refactoring:
- The wasm interpreter now unwraps import wrappers on demand, instead
of unwrapping all of them on instantiation and storing a vector of
handles. This also avoids the DeferredHandleScope completely, instead
we just store two global handles in the code map.
- The interpreter gets the code table, function tables and signature
tables directly from the attached wasm instance object. This ensures
that the interpreter sees all updates to tables that might have been
performed by external code.
- There is now common functionality for calling a code object. This is
used for direct calls to imported functions and for all indirect
calls. As these code objects can also be wasm functions which should
be executed in the interpreter itself, I introduce a struct to hold
the outcome of calling the code object, or a pointer to
InterpreterCode to be called in the interpreter.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: I20fb2ea007e79e5fcff9afb4b1ca31739ebcb83f
Reviewed-on: https://chromium-review.googlesource.com/458417
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44059}
This is a cleanup in preparation to implement calling imported
functions via the wasm interpreter.
For imported functions, we do not create entries in the
interpreter_code_ vector any more.
I also simplified the interface and removed unused or redundant return
values. More things are now DCHECKed instead of bailing out.
Also, we previously had two PushFrame methods: One is supposed to
initialize the interpreter from external code (i.e. adds the first
frame to the stack), the other one is used to push new frames on the
frame stack for called functions. This CL renames the first to
InitFrame, and makes it use the second one. The other remaining user is
the DoCall method.
R=titzer@chromium.org
BUG=v8:5822
Change-Id: Id09ff1e3256428fbd8c955e4664507a0c3167e53
Reviewed-on: https://chromium-review.googlesource.com/453482
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43793}
This makes it easier to implement asynchronous compilation by hiding all the implementation details of both synchronous and asynchronous compilation within wasm-module.cc, whereas before the code in wasm-js.cc actually implemented asynchronous compilation in terms of synchronous.
BUG=
Review-Url: https://codereview.chromium.org/2695813005
Cr-Commit-Position: refs/heads/master@{#43310}
This is more renaming work to comply with the naming in the public
design repository. E.g. types are called "value types" and we no longer
refer to ASTs.
R=clemensh@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2594993002
Cr-Commit-Position: refs/heads/master@{#41891}
The new object will hold information which is shared by all clones of a
WasmCompiledModule, e.g. the decoded asm.js offset table, and in the
future also breakpoints. From there, we can set them on each new
instantiation of any clone.
While already changing lots of the code base, I also renamed all
getters from "get_foo" to "foo", to conform to the style guide.
R=titzer@chromium.org, yangguo@chromium.org
BUG=v8:5732
Review-Url: https://codereview.chromium.org/2591653002
Cr-Commit-Position: refs/heads/master@{#41862}
These byte pointers (module_start and module_end) were only valid
during decoding. During instantiation or execution, they can get
invalidated by garbage collection.
This CL removes them from the WasmModule struct, and introduces a new
ModuleStorage struct as interface to the wasm wire bytes.
Since the storage is often needed together with the ModuleEnv, a new
ModuleStorageEnv struct holds both a ModuleEnv and a ModuleStorage.
The pointers in the ModuleStorage should never escape the live range of
this struct, as they might point into a SeqOneByteString or ArrayBuffer.
Therefore, the WasmInterpreter needs to create its own copy of the
whole module.
Runtime functions that previously used the raw pointers in WasmModule
(leading to memory errors) now have to use the SeqOneByteString in the
WasmCompiledModule.
R=titzer@chromium.org
BUG=chromium:669518
Review-Url: https://codereview.chromium.org/2540133002
Cr-Commit-Position: refs/heads/master@{#41388}
This CL adds the function verification option to the module decoder.
Therefore we can remove the verification in wasm-module-runner.cc
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2496203002
Cr-Commit-Position: refs/heads/master@{#40977}
This CL moves all heap-allocated WASM data structures, both ones
that are bonafide JSObjects and ones that are FixedArrays only, into a
consistent place with consistent layout. Note that not all accessors are complete, and I haven't fully spread the new static typing goodness
to all places in the code.
R=ahaas@chromium.org,rossberg@chromium.org
CC=gdeepti@chromium.org,mtrofin@chromium.org,clemensh@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2490663002
Cr-Commit-Position: refs/heads/master@{#40913}
The bounds check in LoadDataSegment was off by one. I also improved the
error message, and fixed an issue where data was initialized even if
the bounds check failed.
In InstantiateModuleForTesting I allow instantiation of modules without
exports. This check was legacy code from the time where instantiation
and execution was still combined in a single function.
R=titzer@chromium.org, rossberg@chromium.org
TEST=cctest/test-run-wasm-module/InitDataAtTheUpperLimit
Review-Url: https://codereview.chromium.org/2486183002
Cr-Commit-Position: refs/heads/master@{#40856}
The wasm specification does not fully specify the binary representation
of NaN: the sign bit can be non-deterministic. The wasm-code fuzzer
found a test case where the wasm interpreter and the compiled code
produce a different sign bit for a NaN, and as a consequence they
produce different results.
With this CL the interpreter tracks whether it executed an instruction
which can produce a NaN, which are div and sqrt instructions. The
fuzzer uses this information and compares the result of the interpreter
with the result of the compiled code only if there was no instruction
which could have produced a NaN.
R=titzer@chromium.org
TEST=cctest/test-run-wasm-interpreter/TestMayProduceNaN
BUG=chromium:657481
Review-Url: https://chromiumcodereview.appspot.com/2438603003
Cr-Commit-Position: refs/heads/master@{#40474}
This CL refactors the handling of metadata associated with WebAssembly
modules to reduce the duplicate marshalling of data from the C++ world
to the JavaScript world. It does this by wrapping the C++ WasmModule*
object in a Foreign that is rooted from the on-heap WasmCompiledModule
(which is itself just a FixedArray). Upon serialization, the C++ object
is ignored and the original WASM wire bytes are serialized. Upon
deserialization, the C++ object is reconstituted by reparsing the bytes.
This is motivated by increasing complications in implementing the JS
API, in particular WebAssembly.Table, which must perform signature
canonicalization across instances.
Additionally, this CL implements the proper base + offset initialization
behavior for tables.
R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
BUG=v8:5507, chromium:575167, chromium:657316
Review-Url: https://chromiumcodereview.appspot.com/2424623002
Cr-Commit-Position: refs/heads/master@{#40434}
This adds more useful information to the v8-heap-stats tool.
BUG=v8:5489
Review-Url: https://codereview.chromium.org/2394213003
Cr-Commit-Position: refs/heads/master@{#40361}
For the asm.js to WASM pipeline, the current stack traces only show
low-level WASM information.
This CL maps this back to asm.js source positions.
It does so by attaching the asm.js source Script to the compiled WASM
module, and emitting a delta-encoded table which maps from WASM byte
offsets to positions within that Script. As asm.js code does not throw
exceptions, we only store a mapping for call instructions.
The new AsmJsWasmStackFrame implementation inherits from
WasmStackFrame, but contains the logic to provide the source script and
the position inside of it.
What is still missing is the JSFunction object returned by
CallSite.getFunction(). We currently return null.
R=jgruber@chromium.org, titzer@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2404253002
Cr-Commit-Position: refs/heads/master@{#40205}
- Store instruction with an offset bigger than GrowMemory offset should handle out of bounds correctly
- Refactor to separate runnning from compile so arguments can be passed in to module builder tests.
BUG=chromium:644670
R=ahaas@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2373613004
Cr-Commit-Position: refs/heads/master@{#39840}
[0xC] Convert to stack machine semantics.
[0xC] Use section codes instead of names.
[0xC] Add elements section decoding.
[0xC] Decoding of globals section.
[0xC] Decoding of memory section.
[0xC] Decoding of imports section.
[0xC] Decoding of exports section.
[0xC] Decoding of data section.
[0xC] Remove CallImport bytecode.
[0xC] Function bodies have an implicit block.
[0xC] Remove the bottom label from loops.
[0xC] Add signatures to blocks.
[0xC] Remove arities from branches.
Add tests for init expression decoding.
Rework compilation of import wrappers and how they are patched.
Rework function indices in debugging.
Fix ASM->WASM builder for stack machine.
Reorganize asm.js foreign functions due to import indices change.
R=ahaas@chromium.org,rossberg@chromium.org,bradnelson@chromium.org
BUG=chromium:575167
LOG=Y
Committed: https://crrev.com/76eb976a67273b8c03c744f64ad850b0432554b9
Review-Url: https://codereview.chromium.org/2345593003
Cr-Original-Commit-Position: refs/heads/master@{#39678}
Cr-Commit-Position: refs/heads/master@{#39795}
Reason for revert:
Main suspect for tsan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/11893
Also changes layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/10036
+mips builder:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/4032
Original issue's description:
> [wasm] Master CL for Binary 0xC changes.
>
> [0xC] Convert to stack machine semantics.
> [0xC] Use section codes instead of names.
> [0xC] Add elements section decoding.
> [0xC] Decoding of globals section.
> [0xC] Decoding of memory section.
> [0xC] Decoding of imports section.
> [0xC] Decoding of exports section.
> [0xC] Decoding of data section.
> [0xC] Remove CallImport bytecode.
> [0xC] Function bodies have an implicit block.
> [0xC] Remove the bottom label from loops.
> [0xC] Add signatures to blocks.
> [0xC] Remove arities from branches.
> Add tests for init expression decoding.
> Rework compilation of import wrappers and how they are patched.
> Rework function indices in debugging.
> Fix ASM->WASM builder for stack machine.
> Reorganize asm.js foreign functions due to import indices change.
>
> R=ahaas@chromium.org,rossberg@chromium.org,bradnelson@chromium.org
> BUG=chromium:575167
> LOG=Y
>
> Committed: https://crrev.com/76eb976a67273b8c03c744f64ad850b0432554b9
> Cr-Commit-Position: refs/heads/master@{#39678}
TBR=ahaas@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,rossberg@chromium.org,bradnelson@google.com,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:575167
Review-Url: https://codereview.chromium.org/2361053004
Cr-Commit-Position: refs/heads/master@{#39685}
[0xC] Convert to stack machine semantics.
[0xC] Use section codes instead of names.
[0xC] Add elements section decoding.
[0xC] Decoding of globals section.
[0xC] Decoding of memory section.
[0xC] Decoding of imports section.
[0xC] Decoding of exports section.
[0xC] Decoding of data section.
[0xC] Remove CallImport bytecode.
[0xC] Function bodies have an implicit block.
[0xC] Remove the bottom label from loops.
[0xC] Add signatures to blocks.
[0xC] Remove arities from branches.
Add tests for init expression decoding.
Rework compilation of import wrappers and how they are patched.
Rework function indices in debugging.
Fix ASM->WASM builder for stack machine.
Reorganize asm.js foreign functions due to import indices change.
R=ahaas@chromium.org,rossberg@chromium.org,bradnelson@chromium.org
BUG=chromium:575167
LOG=Y
Review-Url: https://codereview.chromium.org/2345593003
Cr-Commit-Position: refs/heads/master@{#39678}
WasmModule::Instantiate can return an empty handle if it is not possible
to instantiate the module. With this change the wasm-module-runner does
not assume anymore that WasmModule::Instantiate produces a valid handle.
BUG=chromium:648078
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2365493003
Cr-Commit-Position: refs/heads/master@{#39629}
This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.
BUG=v8:5409
Review-Url: https://codereview.chromium.org/2344143003
Cr-Commit-Position: refs/heads/master@{#39558}
test-run-wasm-module cctests broken in debug since recent refactoring changes for moving Compilation/Instantiation off the module object (https://codereview.chromium.org/2320723005). The problem here is that SetupIsolateForWasm tries to add the same property to a module_object multiple times and hits a DCHECK when this property is found on a lookup.
- Fixed to use the setup method only once when CcTest::InitIsolateOnce is used.
- Move setup method to test as this is only used for cctests/fuzzers. The install method should take care of this in the regular JS pipeline.
R=mtrofin@chromium.org, ahaas@chromium.org
Review-Url: https://codereview.chromium.org/2342263002
Cr-Commit-Position: refs/heads/master@{#39484}
All parameters passed by reference must be labeled const.
If the object is mutable, then we pass by pointer.
BUG=
Review-Url: https://codereview.chromium.org/2336233006
Cr-Commit-Position: refs/heads/master@{#39451}
The wasm-module-runner is used both in cctests and in fuzzers. As
discussed offline, it is weird to include cctest header files in
fuzzers, so I introduce a new test/common directory which contains the
common files.
R=titzer@chromium.org, jochen@chromium.org
Review-Url: https://codereview.chromium.org/2335193002
Cr-Commit-Position: refs/heads/master@{#39411}
