Two controls, one for instantiation and one for compilation. They allow
the embedder (e.g. Chrome) check properties of the parameters of those
two operations, and decide if they are allowed to continue.
For example, Chrome may now decline compilation of certain size buffers,
in synchronous cases; same for instantiation (where the buffer size
refers to the size of the buffer containing wasm wire bytes)
BUG=v8:5981
Review-Url: https://codereview.chromium.org/2699843003
Cr-Original-Commit-Position: refs/heads/master@{#43295}
Committed: d9bc0ffb16
Review-Url: https://codereview.chromium.org/2699843003
Cr-Commit-Position: refs/heads/master@{#43336}
Reason for revert:
Introduces a new test failure/flake: https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/16427
Original issue's description:
> [wasm] Embedder can control what buffers wasm compilation works on.
>
> Two controls, one for instantiation and one for compilation. They allow
> the embedder (e.g. Chrome) check properties of the parameters of those
> two operations, and decide if they are allowed to continue.
>
> For example, Chrome may now decline compilation of certain size buffers,
> in synchronous cases; same for instantiation (where the buffer size
> refers to the size of the buffer containing wasm wire bytes)
>
> BUG=v8:5981
>
> Review-Url: https://codereview.chromium.org/2699843003
> Cr-Commit-Position: refs/heads/master@{#43295}
> Committed: d9bc0ffb16TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5981
Review-Url: https://codereview.chromium.org/2701413002
Cr-Commit-Position: refs/heads/master@{#43303}
Two controls, one for instantiation and one for compilation. They allow
the embedder (e.g. Chrome) check properties of the parameters of those
two operations, and decide if they are allowed to continue.
For example, Chrome may now decline compilation of certain size buffers,
in synchronous cases; same for instantiation (where the buffer size
refers to the size of the buffer containing wasm wire bytes)
BUG=v8:5981
Review-Url: https://codereview.chromium.org/2699843003
Cr-Commit-Position: refs/heads/master@{#43295}
We were looking at the unreachable flag or stack_depth of the target frame
instead of the current one in a couple of places (most notably BreakTo).
This change fixes these bugs and makes us pass the latest spec tests for
br_table validation. Also need to ensure that br_table targets have consistent
types, which is not implied if the stack is polymorphic.
R=titzer@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2696813002
Cr-Commit-Position: refs/heads/master@{#43250}
When WebAssembly.Table initial size is greater than the declared initial size, table size references should be updated on instantiate for functions to be called at indices greater than the declared initial size.
R=bradnelson@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2661773002
Cr-Commit-Position: refs/heads/master@{#42781}
Memory.Grow should detach the ArrayBuffer associated with the Mem object after Grow. Currently, when guard pages are enabled protection is changed to make more of the buffer accessible. This does not work for when the buffer should be detached after grow, because the memory object has a reference to the same buffer befor/after grow.
R=titzer@chromium.org, eholk@chromium.org
Review-Url: https://codereview.chromium.org/2653183003
Cr-Commit-Position: refs/heads/master@{#42717}
According to the WebAssembly spec no arithmetic operation should ever
return a signalling NaN. With the constant folding in V8, however, it
was possible that some arithmetic operations were elided, and if the
input of the arithmetic operation was a signalling NaN, then also the
result was the same signalling NaN. This CL removes some constant
folding optimizations and adjusts others so that even with constant
folding the result of an arithmetic operation is never a signalling NaN.
R=titzer@chromium.org, rossberg@chromium.org, bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2647353007
Cr-Commit-Position: refs/heads/master@{#42694}
A recent change to disallow wasm compilation in contexts where
CSP unsafe-eval would disallow eval also ended up banning asm.js there:
https://codereview.chromium.org/2646713002
This ends up banning non-evaled asm.js even in some places it should be
allowed.
NOTE: Although asm.js code converted to wasm generates an intermediate wasm
module. asm.js code evaled in a disallowed context can't even get
that far (as it's stoped at the eval site).
BUG=683867
R=mtrofin@chromium.org,titzer@chromium.org,adamk@chromium.org
Review-Url: https://codereview.chromium.org/2656463004
Cr-Commit-Position: refs/heads/master@{#42616}
- Currently WebAssembly.Memory.grow() assumes that it always has an instance associated with it,
fix to grow and reflect new size when no instance is associated with memory object.
- Correctness fixes for the js api, throw range errors instead of generic errors
BUG=chromium:680938
R=bradnelson@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2638243002
Cr-Commit-Position: refs/heads/master@{#42432}
Reason for revert:
OK, the failure really does seem to be due to this patch: It triggers Clang to crash
FAILED: obj/test/unittests/unittests/function-body-decoder-unittest.obj
E:\b\build\slave\cache\cipd\goma/gomacc.exe ../../third_party/llvm-build/Release+Asserts/bin/clang-cl.exe /nologo /showIncludes /FC @obj/test/unittests/unittests/function-body-decoder-unittest.obj.rsp /c ../../test/unittests/wasm/function-body-decoder-unittest.cc /Foobj/test/unittests/unittests/function-body-decoder-unittest.obj /Fd"obj/test/unittests/unittests_cc.pdb"
Assertion failed: (NumGaps == 0 || Bias < MaxDefRange) && "large ranges should not have gaps", file E:\b\build\slave\win_upload_clang\build\src\third_party\llvm\lib\MC\MCCodeView.cpp, line 531
Wrote crash dump file "C:\Users\CHROME~2\AppData\Local\Temp\goma_temp.5068\clang-cl.exe-563144.dmp"
Let's leave it out for now.
Original issue's description:
> Reland of [wasm] Enforce that function bodies end with the \"end\" opcode. (patchset #1 id:1 of https://codereview.chromium.org/2628883006/ )
>
> Reason for revert:
> Try a reland; this might not have been the source of tree-closing.
>
> Original issue's description:
> > Revert of [wasm] Enforce that function bodies end with the \"end\" opcode. (patchset #3 id:40001 of https://codereview.chromium.org/2630553002/ )
> >
> > Reason for revert:
> > Caused tree to close by failing compilation:
> >
> > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/4451
> >
> > Original issue's description:
> > > [wasm] Enforce that function bodies end with the \"end\" opcode.
> > >
> > > R=rossberg@chromium.org
> > > BUG=chromium:575167
> > >
> > > Review-Url: https://codereview.chromium.org/2630553002
> > > Cr-Commit-Position: refs/heads/master@{#42286}
> > > Committed: fcc6e85ec6
> >
> > TBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,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/2628883006
> > Cr-Commit-Position: refs/heads/master@{#42287}
> > Committed: 1d32a3989b
>
> TBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,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/2628203003
> Cr-Commit-Position: refs/heads/master@{#42296}
> Committed: e539bd8e0eTBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,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/2633583002
Cr-Commit-Position: refs/heads/master@{#42298}
Reason for revert:
Try a reland; this might not have been the source of tree-closing.
Original issue's description:
> Revert of [wasm] Enforce that function bodies end with the \"end\" opcode. (patchset #3 id:40001 of https://codereview.chromium.org/2630553002/ )
>
> Reason for revert:
> Caused tree to close by failing compilation:
>
> https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/4451
>
> Original issue's description:
> > [wasm] Enforce that function bodies end with the \"end\" opcode.
> >
> > R=rossberg@chromium.org
> > BUG=chromium:575167
> >
> > Review-Url: https://codereview.chromium.org/2630553002
> > Cr-Commit-Position: refs/heads/master@{#42286}
> > Committed: fcc6e85ec6
>
> TBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,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/2628883006
> Cr-Commit-Position: refs/heads/master@{#42287}
> Committed: 1d32a3989bTBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,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/2628203003
Cr-Commit-Position: refs/heads/master@{#42296}
- updated WebAssembly.Instance ctor uses in our tests to match spec
- disallowing mem section *and* mem import, as per spec
BUG=v8:5824
Review-Url: https://codereview.chromium.org/2627763002
Cr-Commit-Position: refs/heads/master@{#42278}
Also ensuring it is validation error to specify more than
one memory import.
BUG=v8:5824
Review-Url: https://codereview.chromium.org/2624853002
Cr-Commit-Position: refs/heads/master@{#42205}
We did not associate any position to the stack check in the wasm
function prologue, hence a check failed later when trying to map the
non-existent position to the asm.js source position.
With this CL, we add a mapping to the source position table, mapping
the stack check call to byte offset 0 (which is distinct from any valid
instruction position). Also, we add another entry to the asm.js source
position sidetable, mapping byte offset 0 to the start source position
of the function body.
R=titzer@chromium.org, ahaas@chromium.org
BUG=chromium:677685
Review-Url: https://codereview.chromium.org/2609363004
Cr-Commit-Position: refs/heads/master@{#42130}
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}
Some instructions in WebAssembly trap for some inputs, which means that the
execution is terminated and (at least at the moment) a JavaScript exception is
thrown. Examples for traps are out-of-bounds memory accesses, or integer
divisions by zero.
Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
constant), in addition to the trap condition itself. Additionally, each
WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
number of inputs is linear to the number of trap checks in the function.
Especially for functions with high numbers of trap checks we observe a
significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
a TrapIf common operator only a single node is necessary per trap check, in
addition to the trap condition. Also the nodes which are shared between trap
checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
speedup of 30-50% on average.
This CL only implements TrapIf and TrapUnless on x64. The implementation is also
hidden behind the --wasm-trap-if flag.
Please take a special look at how the source position is transfered from the
instruction selector to the code generator, and at the context that is used for
the runtime call.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2562393002
Cr-Commit-Position: refs/heads/master@{#41720}
WASM exported functions have additional internal fields which change the instance
size. Adding a getter or setter to such an exported function results in its map
becoming normalized. The normalized map cache, however, finds a different map
with a different instance size, and thus BOOM.
R=verwaest@chromium.org,cbruni@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2554343002
Cr-Commit-Position: refs/heads/master@{#41691}
This CL moves all methods related to scripts and eval origin (HasScript,
GetScript, IsEval, GetEvalOrigin) from JSStackFrame to StackFrameBase,
because it also applies to WasmFrames.
This makes the AppendFileLocation method append the same information to
WasmStackFrames and AsmJsWasmStackFrames than to JSStackFrames.
R=titzer@chromium.org, mstarzinger@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2557923005
Cr-Commit-Position: refs/heads/master@{#41642}
By now the predicate in question is an exact negation of %IsAsmWasmCode
as the name intuitively implies. The need for two separate test methods
no longer exists and one of the two can be removed.
R=bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2562003002
Cr-Commit-Position: refs/heads/master@{#41616}
In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").
This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
table, but two (one for the call, one for the parent which does the
type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
two calls in the WASM_TO_JS wrapper (only if the module origin is
asm.js).
- the StackFrame::State struct now also holds the callee_pc_address,
which is set in ComputeCallerState. The WASM frame uses this
information to determine whether the callee frame is WASM_TO_JS, and
whether that frame is at the ToNumber conversion call.
- the same information is also stored in the FrameArray which is used
to reconstruct the stack trace later.
R=titzer@chromium.org, bradnelson@chromium.orgCC=jgruber@chromium.org
BUG=v8:4203,v8:5724
Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
Review-Url: https://codereview.chromium.org/2555243002
Cr-Original-Commit-Position: refs/heads/master@{#41599}
Cr-Commit-Position: refs/heads/master@{#41613}
Reason for revert:
gc-stress failures
Original issue's description:
> [wasm] Fix location for error in asm.js ToNumber conversion
>
> In the asm.js code translated to wasm, we call imported functions via a
> WASM_TO_JS stub, which first calls the function and then calls ToNumber
> on the return value. Exceptions can happen in both calls.
> We were only ever reporting the location of the function call, whereas
> asm.js code executed via turbofan reported the location of the type
> coercion operator ("+" on "+foo()" or "|" on "foo()|0").
>
> This CL implements the same behaviour for asm.js code translated to
> wasm. The following is changed:
> - the AsmWasmBuilder records the parent node when descending on a binary
> operator (also "+foo()" is represented by a binary operation).
> - it stores not one location per call in the source position side
> table, but two (one for the call, one for the parent which does the
> type coercion).
> - the wasm compiler annotates the source positions "0" and "1" to the
> two calls in the WASM_TO_JS wrapper (only if the module origin is
> asm.js).
> - during stack trace generation (in the StackTraceIterator), when we
> move from the WASM_TO_JS frame to the WASM frame, we remember at which
> call inside the WASM_TO_JS wrapper we are, and encode this information
> in the generated caller state, used for the WASM frame.
> - the same information is also stored in the FrameArray which is used
> to reconstruct the stack trace later.
>
> R=titzer@chromium.org, bradnelson@chromium.org
> CC=jgruber@chromium.org
> BUG=v8:4203,v8:5724
>
> Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
> Cr-Commit-Position: refs/heads/master@{#41599}
TBR=bradnelson@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4203,v8:5724
Review-Url: https://codereview.chromium.org/2563613003
Cr-Commit-Position: refs/heads/master@{#41601}
In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").
This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
table, but two (one for the call, one for the parent which does the
type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
two calls in the WASM_TO_JS wrapper (only if the module origin is
asm.js).
- during stack trace generation (in the StackTraceIterator), when we
move from the WASM_TO_JS frame to the WASM frame, we remember at which
call inside the WASM_TO_JS wrapper we are, and encode this information
in the generated caller state, used for the WASM frame.
- the same information is also stored in the FrameArray which is used
to reconstruct the stack trace later.
R=titzer@chromium.org, bradnelson@chromium.orgCC=jgruber@chromium.org
BUG=v8:4203,v8:5724
Review-Url: https://codereview.chromium.org/2555243002
Cr-Commit-Position: refs/heads/master@{#41599}
There were two bugs, one partly hiding the other one:
1) We generate the ToNumber conversion for each WASM_TO_JS wrapper,
even if the expected return type is void.
2) The return node in the WASM_TO_JS wrapper did not use the effect of
the ToNumber conversion.
This CL fixes both, and adds test cases to check that we do throw an
error trying to convert (e.g.) Symbol to a number, but only if the
return type is not void.
Additional test check that a user-provided valueOf method is actually
called the correct number of times.
R=titzer@chromium.org, bradnelson@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2552123004
Cr-Commit-Position: refs/heads/master@{#41552}
In the current implementation, WasmInstanceWrapper is allocated after the imports for the instance are processed, and before the InstanceFinalizer callback is associated with the instance. This raises the possibility of triggering a gc in the middle of the instantiate flow which is incorrect.
BUG=5707
R=titzer@chromium.org, petermarshall@chromium.org
Review-Url: https://codereview.chromium.org/2544273002
Cr-Commit-Position: refs/heads/master@{#41464}
Make the AsmWasmBuilder drive the process of typing and potentially parsing
function bodies. This will allow us to keep only a single asm.js function's
AST in memory as we convert to WebAssembly.
This is needed to keep our memory footprint low.
Add some additional output to a few tests that's helpful to see which stage they fail at.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=marja@chromium.org,adamk@chromium.org,aseemgarg@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2398023002
Cr-Commit-Position: refs/heads/master@{#41372}
Up until now assertThrows allows to check the type field of an
exception, which is, however, a custom field introduced in a single
regression test. With the change assertThrows allows to check the
message field of an exception, which is set for standard V8 exceptions
by default.
I use the new assertThrows to refactor test/mjsunit/wasm/divrem-trap.js
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2525313003
Cr-Commit-Position: refs/heads/master@{#41302}
Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
- Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
- Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
- MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
- Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.
R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org
Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
Committed: https://crrev.com/3c98e339599b068f1ed630afb7601ff942424d31
Review-Url: https://codereview.chromium.org/2471883003
Cr-Original-Original-Commit-Position: refs/heads/master@{#41121}
Cr-Original-Commit-Position: refs/heads/master@{#41198}
Cr-Commit-Position: refs/heads/master@{#41234}
Reason for revert:
Test crashes after an unrelated revert: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/7189
Reverting because of recommendation from WASM team.
Original issue's description:
> [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects.
>
> Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
> - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
> - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
> - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
> - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.
>
> R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org
>
> Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
> Committed: https://crrev.com/3c98e339599b068f1ed630afb7601ff942424d31
> Cr-Original-Commit-Position: refs/heads/master@{#41121}
> Cr-Commit-Position: refs/heads/master@{#41198}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,titzer@chromium.org,gdeepti@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2529573002
Cr-Commit-Position: refs/heads/master@{#41208}
Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
- Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
- Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
- MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
- Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.
R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org
Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
Review-Url: https://codereview.chromium.org/2471883003
Cr-Original-Commit-Position: refs/heads/master@{#41121}
Cr-Commit-Position: refs/heads/master@{#41198}
Wasm frames are special in that they have a non-integer script id
in inspector. The way we treat script ids currently is a bit of a mess -
our runtime functions expected integer IDs while inspector has string
IDs (which contain integers, except for Wasm frames). This will need to
be cleaned up once more Wasm tests are added.
The meaning of line/column numbers has also changed; the old JS debug
API encoded the function index and byte offset into line/column numbers,
while inspector-based API actually translates into lines/columns in the
disassembly.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2515133003
Cr-Commit-Position: refs/heads/master@{#41182}
Reason for revert:
Breaks gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/7114
Original issue's description:
> [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects.
>
> Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
> - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
> - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
> - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
> - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.
>
> R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org
>
> Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
> Cr-Commit-Position: refs/heads/master@{#41121}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,titzer@chromium.org,gdeepti@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2512323004
Cr-Commit-Position: refs/heads/master@{#41122}
Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
- Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
- Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
- MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
- Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.
R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2471883003
Cr-Commit-Position: refs/heads/master@{#41121}
Object::GetProperty fails if the given name is a valid array index.
This CL switches to Object::GetPropertyOrElement for lookups of imports.
The new tests check that we now accept numbers as module name or
function name in FFI.
R=ahaas@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2503313002
Cr-Commit-Position: refs/heads/master@{#41022}
Before, we allocated one script per function per instance, and each
script referenced the wasm instance and the function index. Now we only
allocate one script per compiled wasm module, so the script also only
references this WasmCompiledModule, which causes changes to many interfaces.
Instead of fixing the disassemble API only used via debug.js, I decided
to drop it for now. Some later CL will reintroduce it via
DebugInterface.
BUG=v8:5530,chromium:659715
R=yangguo@chromium.org, titzer@chromium.orgCC=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2493823003
Cr-Commit-Position: refs/heads/master@{#41004}
According to the spec, import wrappers are only generated for JavaScript
functions, not for WebAssembly function. If an imported WebAssembly
function does not have the expected type, then a type error is thrown.
R=titzer@chromium.org, rossberg@chromium.org
TEST=mjsunit/wasm/test-import-export-wrapper
Review-Url: https://codereview.chromium.org/2486943005
Cr-Commit-Position: refs/heads/master@{#40901}
The spec defines that indirect calls in WebAssembly code should cause a
validation error if no function table exists.
The CL contains the following changes:
1) Throw a validation error for indirect calls if the function table
not exist.
2) Do not create TF nodes to throw a runtime error for indirect calls
if the function table does not exist.
3) Fix existing unit tests by creating a dummy function table.
4) Add new a new test which tests that indirect calls without function
table cause a validation error.
R=rossberg@chromium.orgCC=titzer@chromium.org
TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash
Review-Url: https://codereview.chromium.org/2484623002
Cr-Commit-Position: refs/heads/master@{#40852}
This moves all tests currently working with the inspector debugger wrapper to
test/debugger.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2480223002
Cr-Commit-Position: refs/heads/master@{#40824}
- When module bytes have a memory maximum defined, compiled module object should set maximum memory
- Exported memory objects should set maximum value on the memory objects
- Update tests to use declared maximum values.
R=ahaas@chromium.org
Review-Url: https://codereview.chromium.org/2474333003
Cr-Commit-Position: refs/heads/master@{#40820}
Reason for revert:
Speculative revert for blocking roll:
https://codereview.chromium.org/2479233002/
Original issue's description:
> [wasm] Indirect calls without function table cause validation errors.
>
> The spec defines that indirect calls in WebAssembly code should cause a
> validation error if no function table exists.
>
> The CL contains the following changes:
> 1) Throw a validation error for indirect calls if the function table
> not exist.
> 2) Do not create TF nodes to throw a runtime error for indirect calls
> if the function table does not exist.
> 3) Fix existing unit tests by creating a dummy function table.
> 4) Add new a new test which tests that indirect calls without function
> table cause a validation error.
>
> R=rossberg@chromium.org
> CC=titzer@chromium.org
>
> TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash
TBR=rossberg@chromium.org,titzer@chromium.org,ahaas@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2479283002
Cr-Commit-Position: refs/heads/master@{#40811}
This moves all tests currently working with the inspector debugger wrapper to
test/debugger.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2480223002
Cr-Commit-Position: refs/heads/master@{#40804}
The spec defines that indirect calls in WebAssembly code should cause a
validation error if no function table exists.
The CL contains the following changes:
1) Throw a validation error for indirect calls if the function table
not exist.
2) Do not create TF nodes to throw a runtime error for indirect calls
if the function table does not exist.
3) Fix existing unit tests by creating a dummy function table.
4) Add new a new test which tests that indirect calls without function
table cause a validation error.
R=rossberg@chromium.orgCC=titzer@chromium.org
TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash
Review-Url: https://codereview.chromium.org/2484623002
Cr-Commit-Position: refs/heads/master@{#40802}
This makes sure the test in question does not rely on specific lifetime
characteristics for local variables within a function. Note that these
lifetimes are not specified by JavaScript and are not observable within
JavaScript proper. The natives syntax however makes it observable.
BUG=v8:5345
TEST=mjsunit/wasm/compiled-module-management
R=mtrofin@chromium.org
Review-Url: https://codereview.chromium.org/2474053002
Cr-Commit-Position: refs/heads/master@{#40733}
If a WebAssembly function is exported, its js-to-wasm wrapper has a
field which contains a reference to the WebAssembly function.
Originally this reference was an index into the export table, which
then contains an index into the function table, which then contains
the metadata of the WebAssembly function.
With this CL we use the index into the function table directly as
the reference to the WebAssembly function.
TEST=mjsunit/wasm/test-import-export-wrapper
R=rossberg@chromium.org, mtrofin@chromium.orgCC=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2472103002
Cr-Commit-Position: refs/heads/master@{#40729}
This enables Ignition unconditionally for all code that is destined for
optimization with TurboFan. This ensures all optimization attempts will
go through the BytecodeGraphBuilder and that the AstGraphBuilder pipe is
dried out in practice.
patch from issue 2427953002 at patchset 120001 (http://crrev.com/2427953002#ps120001)
R=mvstanton@chromium.org,rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2453973004
Cr-Commit-Position: refs/heads/master@{#40663}
Since the public API for deserialization is now just DeserializeOrCompile,
we can trickle down the wire bytes to the deserialization logic, and
avoid the need for duplicating the wire bytes when serializing.
BUG=chromium:657316
Review-Url: https://chromiumcodereview.appspot.com/2433273002
Cr-Commit-Position: refs/heads/master@{#40516}
When the instance has imported memory, calling GrowMemory should update the memory object to have a consistent view of the memory. This fixes the failing emscripten test case, added a reduced test that simulates the same behavior.
R=titzer@chromium.org, dschuff@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2438673006
Cr-Commit-Position: refs/heads/master@{#40490}
This enables Ignition unconditionally for all code that is destined for
optimization with TurboFan. This ensures all optimization attempts will
go through the BytecodeGraphBuilder and that the AstGraphBuilder pipe is
dried out in practice.
R=mvstanton@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2427953002
Cr-Commit-Position: refs/heads/master@{#40462}
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 CL fixes the debugger interface to provide correct (high-level)
information for asm.js frames.
It moves the computation of the source position from the FrameInspector
to the individual StackFrame implementations, such that we can easily
specualize it for certain frame types, and can potentially reuse this
in other locations.
Also, we are finalizing the setup of the wasm module earlier, before
executing the start function. This is required for correct stack traces
during the execution of the start function.
R=titzer@chromium.org, yangguo@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2413693003
Cr-Commit-Position: refs/heads/master@{#40268}
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}
- Added gating code in the module-decoder to allow SIMD code only when
it can be decoded correctly
- SIMD128 values should not be exported to JS
- Try/Catch should not be available in asmjs modules
- Trivial fixes for S128 values
BUG=chromium:648079
R=ahaas@chromium.org, titzer@chromium.org, bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2400863003
Cr-Commit-Position: refs/heads/master@{#40067}
Imports and exports in 0xC can be much more than functions, including
tables, memories, and globals. This CL refactors the underlying
organization of imports and exports to support these new import types.
BUG=
Committed: https://crrev.com/599f8a83420346d9cba5ff97bd2a7520468207b6
Review-Url: https://codereview.chromium.org/2390113003
Cr-Original-Commit-Position: refs/heads/master@{#40033}
Cr-Commit-Position: refs/heads/master@{#40050}
Imports and exports in 0xC can be much more than functions, including
tables, memories, and globals. This CL refactors the underlying
organization of imports and exports to support these new import types.
BUG=
Review-Url: https://codereview.chromium.org/2390113003
Cr-Commit-Position: refs/heads/master@{#40033}
Allow fround to take values without dots for globals (the spec allows this
subtly).
Drop over-restrictive assert preventing floating point globals from working.
BUG=v8:4203
R=jpp@chromium.org,aseemgarg@chromium.org
Review-Url: https://codereview.chromium.org/2397823003
Cr-Commit-Position: refs/heads/master@{#40013}
The implementation of MemorySize with RelocatableInt32Constants is
problematic if MemorySize is placed close to a GrowMemory instruction in
the code. The use of a runtime function guarantees that the order in
which MemorySize and GrowMemory is executed is correct.
R=titzer@chromium.org
BUG=chromium:651961
TEST=mjsunit/regress/wasm/regression-651961
Committed: https://crrev.com/2c12a9a42d454a36fcd2931fa458d72832eeb689
Review-Url: https://codereview.chromium.org/2386183004
Cr-Original-Commit-Position: refs/heads/master@{#39972}
Cr-Commit-Position: refs/heads/master@{#39980}
This is essentially CL/2275293002, with the difference that the effect
dependencies are now updated correctly.
BUG=
Review-Url: https://codereview.chromium.org/2378773013
Cr-Commit-Position: refs/heads/master@{#39919}
Note that the offset can still be out of bounds, even after grow memory. The calculation of the remaining size can overflow.
R=gdeepti@chromium.org
BUG=chromium:644670
Review-Url: https://codereview.chromium.org/2376153003
Cr-Commit-Position: refs/heads/master@{#39886}
- 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}
The WebAssembly spec requires a HasProperty() check for the maximum
property of the descriptor object which is used to set up a
WebAssembly.Memory object or a WebAssembly.Table object.
The original implementation only approximated the HasProperty() check.
It used Get() to get the value of the maximum property of the descriptor
object and compared the resulting value to {undefined}. However, this
approximation is incorrect if the property exists but its value is
{undefined}.
R=titzer@chromium.org, franzih@chromium.org
BUG=chromium:649461
TEST=mjsunit/wasm/memory
Review-Url: https://codereview.chromium.org/2367673003
Cr-Commit-Position: refs/heads/master@{#39722}
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}
Handle the case of asm.js modules that return a single function
instead of a collection of them.
R=mtrofin@chromium.org
TEST=mjsunit/asm/asm-wasm
BUG=v8:4203
BUG=v8:5356
Review-Url: https://codereview.chromium.org/2348383003
Cr-Commit-Position: refs/heads/master@{#39515}
We'd like wasm regressions to live under a subfolder of the mjsunit
regression folder.
BUG=
Review-Url: https://codereview.chromium.org/2344373002
Cr-Commit-Position: refs/heads/master@{#39483}
Ensure we can serialize a wasm compiled module even after it was
instantiated a few times.
BUG=
Review-Url: https://codereview.chromium.org/2339933003
Cr-Commit-Position: refs/heads/master@{#39463}
This CL implements the throw wasm opcode. This is a pre-requisite for
implementing try-catches in wasm.
BUG=
Review-Url: https://codereview.chromium.org/2339053003
Cr-Commit-Position: refs/heads/master@{#39449}
This change avoids needing to keep around an unused compiled
module. Instead, the result of compiling the wasm bytes is
given to the first instance. The module object and that instance object
point to the same compiled module. Instances are, then, cloned from
the compiled module the module object points to. When an instance is
collected, we make sure that the module object still has a clone
available, and, if the last instance is GC-ed, we also reset the compiled
module so that it does not reference its heap, so that it (==heap) may
be collected.
This is achieved by linking the clones in a double-linked list and
registering a finalizer for each. When we create an instance, we tie it
in the front of the list, making the module object point to it (O(1)). When
the finalizer is called, we relink the list over the dying object (O(1)). The
costliest operation is finalizing the last instance, since we need to visit
all wasm functions and reset heap references.
BUG=v8:5316
Committed: https://crrev.com/01f5af515728aebe6c5246f4f7dd6c573e8748af
Review-Url: https://codereview.chromium.org/2305903002
Cr-Original-Commit-Position: refs/heads/master@{#39153}
Cr-Commit-Position: refs/heads/master@{#39361}
Reason for revert:
mac gc stress failures:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/8341
Original issue's description:
> [wasm] reuse the first compiled module.
>
> This change avoids needing to keep around an unused compiled
> module. Instead, the result of compiling the wasm bytes is
> given to the first instance. The module object and that instance object
> point to the same compiled module. Instances are, then, cloned from
> the compiled module the module object points to. When an instance is
> collected, we make sure that the module object still has a clone
> available, and, if the last instance is GC-ed, we also reset the compiled
> module so that it does not reference its heap, so that it (==heap) may
> be collected.
>
> This is achieved by linking the clones in a double-linked list and
> registering a finalizer for each. When we create an instance, we tie it
> in the front of the list, making the module object point to it (O(1)). When
> the finalizer is called, we relink the list over the dying object (O(1)). The
> costliest operation is finalizing the last instance, since we need to visit
> all wasm functions and reset heap references.
>
> BUG=v8:5316
>
> Committed: https://crrev.com/01f5af515728aebe6c5246f4f7dd6c573e8748af
> Cr-Commit-Position: refs/heads/master@{#39153}
TBR=bradnelson@chromium.org,verwaest@chromium.org,vogelheim@chromium.org,yangguo@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5316
Review-Url: https://codereview.chromium.org/2306403002
Cr-Commit-Position: refs/heads/master@{#39154}
This change avoids needing to keep around an unused compiled
module. Instead, the result of compiling the wasm bytes is
given to the first instance. The module object and that instance object
point to the same compiled module. Instances are, then, cloned from
the compiled module the module object points to. When an instance is
collected, we make sure that the module object still has a clone
available, and, if the last instance is GC-ed, we also reset the compiled
module so that it does not reference its heap, so that it (==heap) may
be collected.
This is achieved by linking the clones in a double-linked list and
registering a finalizer for each. When we create an instance, we tie it
in the front of the list, making the module object point to it (O(1)). When
the finalizer is called, we relink the list over the dying object (O(1)). The
costliest operation is finalizing the last instance, since we need to visit
all wasm functions and reset heap references.
BUG=v8:5316
Review-Url: https://codereview.chromium.org/2305903002
Cr-Commit-Position: refs/heads/master@{#39153}
This disables notification of wasm script 'compilation' since
OnAfterCompile actually triggers a JS call (which is disallowed during
stack trace collection).
BUG=641065
Review-Url: https://codereview.chromium.org/2304943002
Cr-Commit-Position: refs/heads/master@{#39139}
Test ensuring globals are isolated between instances. Also
added support for globals section to mjsunit's
WebModuleBuilder as a prerequisite.
BUG=
Review-Url: https://codereview.chromium.org/2296993002
Cr-Commit-Position: refs/heads/master@{#39028}
If the input of grow-memory was not representable as a SMI, then the
input was not passed correctly to the runtime, which caused a crash.
With this CL the input of grow-memory is checked before the runtime is
called.
R=titzer@chromium.org, gdeepti@chromium.org
TEST=mjsunit/wasm/grow-memory.js:testGrowMemoryTrapsWithNonSmiInput()
Review-Url: https://codereview.chromium.org/2288773002
Cr-Commit-Position: refs/heads/master@{#39022}
With this CL we use isolate->native_context() to provide a context for
the CEntryStub of the runtime call. The native_context() is sufficient
here because Runtime::kWasmThrowTypeError does not use the context.
R=titzer@chromium.org
TEST=mjsunit/wasm/ffi-error.js
BUG=chromium:639492
Review-Url: https://codereview.chromium.org/2291043002
Cr-Commit-Position: refs/heads/master@{#39014}
Make use of %IsAsmWasmCode in place of Wasm.instantiateModuleFromAsm,
in order to reduce the surface area of the Wasm object,
and to focus on testing asm.js coming in via the parser.
Ignore extra CONST_LEGACY assignment introduced by the parser
when modules have the form:
(function Foo(a, b, c) {..});
This requires both a validator and AsmWasmBuilder change.
Move stdlib use collection to import time,
to reject modules that import a function, even if not used.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=jpp@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2264913002
Cr-Commit-Position: refs/heads/master@{#38806}
Record which asm.js stdlib members are used and add a check that NaN is actually correctly set. Other stdlib members to be added in a later change.
Also add a stdlib argument to Wasm.instantiateModuleFromAsm, in preparation for that function to be replaced by normal asm.js instantiation.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=jpp@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2251433002
Cr-Commit-Position: refs/heads/master@{#38760}
As required by the spec, ToJS now throws a TypeError fit I64 values
instead of truncating the I64 value to I32. To throw a TypeError I
introduced a new runtime function because the existing
Runtime::kThrowWasmError does not throw a TypeError. Since we have calls
to two runtime functions now, and an additional one is needed for stack
checks, I extracted the call to runtime functions into a helper function.
R=titzer@chromium.org
TEST=mjsunit/wasm/ffi-error.js:I64InSignatureThrows
Review-Url: https://codereview.chromium.org/2254803002
Cr-Commit-Position: refs/heads/master@{#38718}
With this CL all kinds of Callable can imported into wasm. Please take a special look at the context that is used now in the WasmToJSWrapper.
BUG=633895
TEST=mjsunit/wasm/ffi.js
Review-Url: https://codereview.chromium.org/2208703002
Cr-Commit-Position: refs/heads/master@{#38569}
While we might at some point want to explore if this is a win versus
whole modules, for now we have the Tables interface planned.
R=titzer@chromium.org,ahaas@chromium.org,mtrofin@chromium.org,rossberg@chromium.org
BUG=v8:5044
Review-Url: https://codereview.chromium.org/2226053002
Cr-Commit-Position: refs/heads/master@{#38461}
This patch updates internal data structures used by V8 to support
multiple indirect function tables (WebAssembly/design#682). But, since
this feature is post-MVP, the functionality is not directly exposed and
parsing/generation of WebAssembly is left unchanged. Nevertheless, it
is being used in an experiment to implement fine-grained control flow
integrity based on C/C++ types.
BUG=
Review-Url: https://codereview.chromium.org/2174123002
Cr-Commit-Position: refs/heads/master@{#38110}
This cl also fixes two bugs in the previous code:
1) JITed functions were not allowed access to the heap because the module instance wasn't correctly synthesized. This wasn't discovered in the previous test.
2) Decoding of functions with the JITSingleFunction opcode was off by 1 as the length of the opcode wasn't computed correctly.
BUG=5044
Review-Url: https://codereview.chromium.org/2168183002
Cr-Commit-Position: refs/heads/master@{#37957}
- Add Simd128 type to Wasm AST types
- Add a pass that converts SIMD machine ops to runtime calls
- Sample opcodes Int32x4Splat, Int32x4ExtractLane and test
- Separate out generic SIMD Machine ops as these cannot be
handled by runtime functions just yet.
LOG=N
BUG=v8:4124
R=bradnelson@chromium.org, bbudge@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/1991143002
Cr-Commit-Position: refs/heads/master@{#37789}
Implemented the WebAssembly.Module and WebAssembly.Instance
in terms of the WasmModule::CompileFunctions and
WasmModule::Instantiate APIs.
Added negative tests - for invalid module object.
BUG=
Review-Url: https://codereview.chromium.org/2121593002
Cr-Commit-Position: refs/heads/master@{#37775}
The runtime JIT function is passed in the function table to hook up the compiled code and the starting address of the memory to locate the bytes to be compiled.
BUG=5044
Review-Url: https://codereview.chromium.org/2137993003
Cr-Commit-Position: refs/heads/master@{#37735}
