We've been passing a context to the compiler, which turns out to be
solely used to determine if we're executing in a specific cctest configuration.
This change adds a configuration to the graph builder that we can use to
explicitly opt out of stack checks and traps. CcTests default to opting out,
except for the few that don't.
Bug:
Change-Id: I4724e31c2a62e9b3ab4feadb788287c374b39f53
Reviewed-on: https://chromium-review.googlesource.com/585779
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46943}
With this patch, rather than embedding the JSReceiver address directly
in the WasmToJS wrappers, we put that in a fixed array with global handle
scope and instead embed the location of the handle and the index in the
wrapper. This ensures that the wrapper doesn't need to be patched if the
GC kicks in. This is needed to get the WASM code off the GCed heap.
R=mtrofin@chromium.org
Bug:
Change-Id: Ie5a77a78cdecec51b04f702c63b8e4285e6a2d8d
Reviewed-on: https://chromium-review.googlesource.com/581682
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46884}
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}
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}
Instead, it is supposed to just return an empty context if it failed.
Also don't invoke interceptors (we don't for the parts that deserialize
from the snapshot anyways).
BUG=v8:5830
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2636903002
Cr-Commit-Position: refs/heads/master@{#42404}
When executing wasm code for testing, we did not create a
WasmInstanceObject and link it to the generated code. This required
some special handling at runtime (mainly for stack trace generation).
This CL always provides the WasmInstanceObject, such that e.g. function
names can be resolved the usual way.
The module bytes referenced by the WasmCompiledModule linked with the
WasmInstanceObject do not hold a valid wasm module yet. Instead, we
just add the bytes we need, and make the objects in WasmModule point to
those bytes (currently only used for function names). Those bytes will
not be parsed at runtime anyway.
R=titzer@chromium.orgCC=jgruber@chromium.org
BUG=v8:5620
Review-Url: https://codereview.chromium.org/2551053002
Cr-Commit-Position: refs/heads/master@{#41809}
The WasmRunner now always holds a TestingModule, and allows to add
several functions to it. The prepares a change to always run wasm code
with a full module behind it, removing the special handling for "no wasm
instance" at runtime (http://crrev.com/2551053002).
This CL here also templatizes the WasmRunner such that the Call method must
be called with the same signature specified for the WasmRunner. This
already catched several mismatches there.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5620
Review-Url: https://codereview.chromium.org/2551043002
Cr-Original-Commit-Position: refs/heads/master@{#41728}
Committed: 2ff5906231
Review-Url: https://codereview.chromium.org/2551043002
Cr-Commit-Position: refs/heads/master@{#41747}
Reason for revert:
Win64 dbg failures
Original issue's description:
> [wasm] Make WasmRunner the central test structure
>
> The WasmRunner now always holds a TestingModule, and allows to add
> several functions to it. The prepares a change to always run wasm code
> with a full module behind it, removing the special handling for "no wasm
> instance" at runtime (http://crrev.com/2551053002).
> This CL here also templatizes the WasmRunner such that the Call method must
> be called with the same signature specified for the WasmRunner. This
> already catched several mismatches there.
>
> R=titzer@chromium.org, ahaas@chromium.org
> BUG=v8:5620
>
> Review-Url: https://codereview.chromium.org/2551043002
> Cr-Commit-Position: refs/heads/master@{#41728}
> Committed: 2ff5906231TBR=ahaas@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:5620
Review-Url: https://codereview.chromium.org/2583543002
Cr-Commit-Position: refs/heads/master@{#41732}
The WasmRunner now always holds a TestingModule, and allows to add
several functions to it. The prepares a change to always run wasm code
with a full module behind it, removing the special handling for "no wasm
instance" at runtime (http://crrev.com/2551053002).
This CL here also templatizes the WasmRunner such that the Call method must
be called with the same signature specified for the WasmRunner. This
already catched several mismatches there.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5620
Review-Url: https://codereview.chromium.org/2551043002
Cr-Commit-Position: refs/heads/master@{#41728}
In captured stack traces, all lines and columns must be 1-based.
Even though this makes things a bit ugly, we have to comply also for
wasm locations, where line and column encode function index and byte
offset (both are originally 0-based).
If we don't comply, the frontend might complain, as e.g. DevTools does.
BUG=chromium:659715
R=yangguo@chromium.org, kozyatinskiy@chromium.orgCC=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2493943002
Cr-Commit-Position: refs/heads/master@{#40971}
We report the byte offset as column number, but devtools assumes them
to be 1-based and subtracts one unconditionally before further
processing it. It's a bit unfortunate, but because of that we have to
just add 1 to the reported column number on the public StackTrace API.
R=ahaas@chromium.org, titzer@chromium.org
BUG=chromium:613110
Review-Url: https://codereview.chromium.org/2071563002
Cr-Commit-Position: refs/heads/master@{#37036}
Empty function names are allowed and are output as such, unnamed
functions or functions with no valid UTF-8 name are output as
"<WASM UNNAMED>", while the CallSite object returns null as the
function name.
R=titzer@chromium.org, yangguo@chromium.org
Review-Url: https://codereview.chromium.org/1970503004
Cr-Commit-Position: refs/heads/master@{#36348}
This changes different locations to extract the reference to the wasm
object and the function index from the stack trace, and make it
available through all the APIs which process stack traces.
The javascript CallSite object now has the new methods isWasm(),
getWasmObject() and getWasmFunctionIndex(); the byte offset is
available via getPosition().
Function names of wasm frames should be fully functional with this
commit, position information works reliably for calls, but not for
traps like unreachable or out-of-bounds accesses.
R=titzer@chromium.org, yangguo@chromium.org
Review-Url: https://codereview.chromium.org/1909353002
Cr-Commit-Position: refs/heads/master@{#36067}
