If an exception is thrown and the wasm interpreter entry frame is
unwound, also the internal frames in the interpreter need to be unwound.
We did not do so before, leaving a corrupted internal state of the wasm
interpreter. Thus reusing it would fail.
This CL fixes this and adds a test which reenters a previously unwound
wasm interpreter. It checks that this works and the correct stack is
returned.
This test also requires support for calling an imported function which
throws, so this change is also included here.
R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822
Change-Id: I12fb843f7a371a4e618b4ac63ed3299667a03a82
Reviewed-on: https://chromium-review.googlesource.com/453938
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43937}
Since TrapIf has been implemented on all platforms, there is no need
anymore for the old WasmTrapHelper code. This CL also removes
TrapIf-specific tests.
R=titzer@chromium.org, clemensh@chromium.org
Change-Id: Ic069598441b7bd63bde2e66f4e536abea5ecebe6
Reviewed-on: https://chromium-review.googlesource.com/452380
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43887}
This behaviour was missing before. If a trap is encountered in the
interpreter, we now throw the right error. With test.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822
Change-Id: I09c23d15fcde32ec586fb6d3094a5ec49155a9a2
Reviewed-on: https://chromium-review.googlesource.com/453839
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43859}
When instantiating the wasm interpreter for debugging, we unwrap all
wasm-to-js wrappers and store the callable objects. The handles are
stored in a DeferredHandleScope and deleted when the InterpreterHandle
(store in WasmDebugInfo) is freed.
A call to an imported function reads the arguments from the stack,
converts them to JS objects, calls the callable, converts back the
return value and pushes it onto the stack.
Reentering the interpreter from the calles JS code is not permitted
yet, but will be in a follow-up CL.
Also, indirect calls to imported functions will have to follow.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822
Change-Id: I66c35053bccb6cf8d416606e4f840d888ccb3b65
Reviewed-on: https://chromium-review.googlesource.com/453838
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@{#43855}
When generating the code for an illegal (non-js-compliant) wrapper for
a js function, we were generating a zero constant of the return type.
This failed on ia32 if the return type is i64.
The correct thing to do is to return two i32 zero constants.
R=titzer@chromium.org
BUG=v8:6104, v8:6096
Change-Id: Idc0dd8d3eef901c22d5278d97f1879b000a18588
Reviewed-on: https://chromium-review.googlesource.com/455857
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43835}
When compiling a wasm to js wrapper for a signature which is not JS
compatible, we generate a runtime call to throw a type error and return
immediately afterwards. We were using the return value of the runtime
call as return value for the wrapper.
This worked for integer return values, since the same registers are
used for tagged values and integer values. For float values, however,
it failed, since the return value needs to be stored in another
register.
R=titzer@chromium.org
BUG=v8:6096
Change-Id: I8f39ea132cd150c3044673d25fa3c3588b4266bf
Reviewed-on: https://chromium-review.googlesource.com/455816
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43821}
These tests fail with the new asm.js parser, because they are invalid under
a more strict reading of the spec.
NOTE: These also fail to validate when run in Firefox.
BUG=v8:4203
BUG=v8:6090
R=aseemgarg@chromium.org,eholk@chromium.org
Review-Url: https://codereview.chromium.org/2745393002
Cr-Commit-Position: refs/heads/master@{#43803}
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}
