R=bbudge@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2385393002
Cr-Commit-Position: refs/heads/master@{#41505}

This CL adds a new header src/debug/interface-types.h, moves the
definition of Location from the debug-interface.h to this new header,
and adds a new definition for the WasmDisassembly types.
This allows to use the types in other implementation files or headers
without having to include the entire debug-interface.h, reducing build
dependencies and compile time (especially for incremental builds).

The WasmDisassembly type replaces the old
std::pair<std::string, std::vector<std::tuple<...>>>, which was a bit
hard to unravel.

R=yangguo@chromium.org, kozyatinskiy@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2529383002
Cr-Commit-Position: refs/heads/master@{#41488}

R=clemensh@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2551463002
Cr-Commit-Position: refs/heads/master@{#41477}

This was somehow missing so far. With this CL, we can disassembly all
functions on AngryBots.

R=titzer@chromium.org, rossberg@chromium.org
BUG=chromium:659715

Review-Url: https://codereview.chromium.org/2552643002
Cr-Commit-Position: refs/heads/master@{#41476}

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}

BUG=v8:4124
TEST:test-run-wasm-simd-lowering
R=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org

Review-Url: https://codereview.chromium.org/2498283002
Cr-Commit-Position: refs/heads/master@{#41443}

- These operations are identical for Float32x4 and Int32x4.
- Make them generic, following the naming for generic Simd128 / S128
opcodes.
- F32x4/I32x4 -> S32x4, similarly to S128
- Float32x4/Int32x4 -> Simd32x4, similarly to Simd128.

LOG=N
BUG=v8:4124

Review-Url: https://codereview.chromium.org/2543773002
Cr-Commit-Position: refs/heads/master@{#41437}

Before, it was a method in wasm namespace, and received a
Handle<WasmCompiledModule>. As it does not allocate on the heap, we can
just make it a non-static method on WasmCompiledModule.

R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2536373007
Cr-Commit-Position: refs/heads/master@{#41429}

Allow a function to be exported multiple times in a asm.js
module.
Remarkably, this had not been working before.

BUG=670057
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2535723009
Cr-Commit-Position: refs/heads/master@{#41416}

The current CHECK/DCHECK implementation fails statically if a signed
value is compared against an unsigned value. The common solution is to
cast on each caller, which is tedious and error-prone (might hide bugs).
This CL implements signed vs. unsigned comparisons by executing up to
two comparisons. For example, if i is int32_t and u is uint_32_t, a
DCHECK_LE(i, u) would create the check
i <= 0 || static_cast<uint32_t>(i) <= u.
For checks against constants, at least one of the checks can be removed
by compiler optimizations.

The tradeoff we have to make is to sometimes silently execute an
additional comparison. And we increase code complexity of course, even
though the usage is just as easy (or even easier) as before.

The compile time impact seems to be minimal:
I ran 3 full compilations for Optdebug on my local machine, one time on
the current ToT, one time with this CL plus http://crrev.com/2524093002.
Before: 143.72 +- 1.21 seconds
Now: 144.18 +- 0.67 seconds

In order to check that the new comparisons are working, I refactored
some DCHECKs in wasm to use the new magic, and added unit test cases.

R=ishell@chromium.org, titzer@chromium.org
CC=ahaas@chromium.org, bmeurer@chromium.org

Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
Review-Url: https://codereview.chromium.org/2526783002
Cr-Original-Commit-Position: refs/heads/master@{#41275}
Cr-Commit-Position: refs/heads/master@{#41411}

During codegen, we build a list mapping protected instructions to their
associated landing pads. This will ultimately by used by the signal handler to
recover from out of bounds faults and throw a JS exception.

This is mostly pulled from my larger in-progress CL at
https://codereview.chromium.org/2371833007/.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2500443004
Cr-Commit-Position: refs/heads/master@{#41400}

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}

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}

Before, the encoded variant was stored in the compiled module, and the
decoded one in the debug info (per instance).
The decoded table was a FixedArray of ByteArrays.
Now, also the decoded table is a flat ByteArray, and it encodes whether
it is encoded or decoded. This saves memory and allows to store encoded
and decoded variant in the same field. The table is automatically
decoded on the first use.

This CL also removes some unused and unimplemented methods from
WasmDebugInfo (probably merge artifacts). That class is now pretty much
empty, but we might still need it for breakpoint support.

R=titzer@chromium.org, ahaas@chromium.org

Review-Url: https://codereview.chromium.org/2522953002
Cr-Commit-Position: refs/heads/master@{#41316}

Revert of [base] Define CHECK comparison for signed vs. unsigned (patchset #5 id:80001 of https://codereview.chromium.org/2526783002/ )

Reason for revert:
Need to revert previous CL because of Android compile error, and this one depends in it.

Original issue's description:
> [base] Define CHECK comparison for signed vs. unsigned
>
> The current CHECK/DCHECK implementation fails statically if a signed
> value is compared against an unsigned value. The common solution is to
> cast on each caller, which is tedious and error-prone (might hide bugs).
> This CL implements signed vs. unsigned comparisons by executing up to
> two comparisons. For example, if i is int32_t and u is uint_32_t, a
> DCHECK_LE(i, u) would create the check
> i <= 0 || static_cast<uint32_t>(i) <= u.
> For checks against constants, at least one of the checks can be removed
> by compiler optimizations.
>
> The tradeoff we have to make is to sometimes silently execute an
> additional comparison. And we increase code complexity of course, even
> though the usage is just as easy (or even easier) as before.
>
> The compile time impact seems to be minimal:
> I ran 3 full compilations for Optdebug on my local machine, one time on
> the current ToT, one time with this CL plus http://crrev.com/2524093002.
> Before: 143.72 +- 1.21 seconds
> Now: 144.18 +- 0.67 seconds
>
> In order to check that the new comparisons are working, I refactored
> some DCHECKs in wasm to use the new magic.
>
> R=bmeurer@chromium.org, titzer@chromium.org
>
> Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
> Cr-Commit-Position: refs/heads/master@{#41275}

TBR=ishell@chromium.org,titzer@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/2531533003
Cr-Commit-Position: refs/heads/master@{#41277}

The current CHECK/DCHECK implementation fails statically if a signed
value is compared against an unsigned value. The common solution is to
cast on each caller, which is tedious and error-prone (might hide bugs).
This CL implements signed vs. unsigned comparisons by executing up to
two comparisons. For example, if i is int32_t and u is uint_32_t, a
DCHECK_LE(i, u) would create the check
i <= 0 || static_cast<uint32_t>(i) <= u.
For checks against constants, at least one of the checks can be removed
by compiler optimizations.

The tradeoff we have to make is to sometimes silently execute an
additional comparison. And we increase code complexity of course, even
though the usage is just as easy (or even easier) as before.

The compile time impact seems to be minimal:
I ran 3 full compilations for Optdebug on my local machine, one time on
the current ToT, one time with this CL plus http://crrev.com/2524093002.
Before: 143.72 +- 1.21 seconds
Now: 144.18 +- 0.67 seconds

In order to check that the new comparisons are working, I refactored
some DCHECKs in wasm to use the new magic.

R=bmeurer@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2526783002
Cr-Commit-Position: refs/heads/master@{#41275}

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}

Revert of [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects. (patchset #13 id:240001 of https://codereview.chromium.org/2471883003/ )

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}

The GetPositionInfo function only operates on WasmCompiledModule, so it
should be a method of that class.
This CL also splits the method in two, such that I can reuse the
GetContainingFunction method for breakpoint support.

R=titzer@chromium.org
BUG=chromium:613110

Review-Url: https://codereview.chromium.org/2521293002
Cr-Commit-Position: refs/heads/master@{#41191}

When disassembling functions for the inspector, we used an internal
text representation before. This CL implements the official text
format like it is understood by the spec interpreter.

Example output:
func $main (param i32) (result i32)
block i32
  get_local 0
  i32.const 2
  i32.lt_u
  if
    i32.const -2
    return
  end
  get_local 0
  call_indirect 0
end

R=rossberg@chromium.org, titzer@chromium.org
BUG=chromium:659715

Review-Url: https://codereview.chromium.org/2520943002
Cr-Commit-Position: refs/heads/master@{#41172}

This fixes a bug found by the fuzzer where we would attempt to
dereference a null handle if memory allocation failed. In this case,
the failure was because the amount of memory requested was above V8's
hardcoded limit.

BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=666741

Review-Url: https://codereview.chromium.org/2514983002
Cr-Commit-Position: refs/heads/master@{#41158}

R=titzer@chromium.org
CC=mtrofin@chromium.org

Review-Url: https://codereview.chromium.org/2520853003
Cr-Commit-Position: refs/heads/master@{#41155}

Revert of [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects. (patchset #10 id:180001 of https://codereview.chromium.org/2471883003/ )

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}

... at least for the function which will remain after restructuring of
the debug interface. For some methods that will be removed anyway, we
just return zero / null for now.

I also refactored the ScriptLocationFromLine method to make it more
readable and reuse parts in other files (like ScriptLinePosition).

BUG=5655
R=titzer@chromium.org, jgruber@chromium.org

Review-Url: https://codereview.chromium.org/2512833003
Cr-Commit-Position: refs/heads/master@{#41115}

This makes wasm frames show up nicely in stack traces generated e.g. by
Isolate::PrintStack() and Isolate::PrintCurrentStackTrace().
With this CL, we print the script name, function index, function name,
pc and source position.

R=titzer@chromium.org, ahaas@chromium.org

Review-Url: https://codereview.chromium.org/2509323002
Cr-Commit-Position: refs/heads/master@{#41102}

With this change, WebAssembly.Memory objects have backing stores allocated as an
8GB region where everything beyond the size of the Wasm heap is inaccessible.

GrowMemory is now implemented by changing the protection on the guard regions to
make the new portions of the heap accessible.

Guard pages are not enabled by default, but this change adds a flag and a test
variant to make sure we get test coverage on them.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2396433008
Cr-Commit-Position: refs/heads/master@{#41089}

With the new wasm object types, the GetCompiledModule and GetWasmBytes
functions are not needed any more. The same functions are already
public on the wasm objects.
In order to use them properly, I changed a few more locations to make
use of the new types.

R=ahaas@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2503403005
Cr-Commit-Position: refs/heads/master@{#41085}

R=titzer@chromium.org
NOTRY=true
NOTREECHECKS=true

Review-Url: https://codereview.chromium.org/2511763002
Cr-Commit-Position: refs/heads/master@{#41082}

The ptr_to_* methods do (often unnecessary) type checks, and can
return nullptr. This is problematic since the handlified getter
uses them, and assumes the result to be non-null. So change
them to only to a DCHECK and never return nullptr, and introduce
maybe_ptr_to_* with the old semantics.

R=titzer@chromium.org, ahaas@chromium.org

Review-Url: https://codereview.chromium.org/2509053003
Cr-Commit-Position: refs/heads/master@{#41079}

This allows to show wasm source (disassembled wasm code) in DevTools.
See design doc for details.

More tests for the disassembly will have to follow. Also, the text
format (generated by V8) will be changed.

BUG=chromium:659715
R=yangguo@chromium.org, kozyatinskiy@chromium.org, titzer@chromium.org, dgozman@chromium.org

Review-Url: https://codereview.chromium.org/2493773003
Cr-Commit-Position: refs/heads/master@{#41055}

R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2502373002
Cr-Commit-Position: refs/heads/master@{#41048}

R=clemensh@chromium.org,mtrofin@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2510673002
Cr-Commit-Position: refs/heads/master@{#41043}

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}

R=clemensh@chromium.org,dschuff@chromium.org
BUG=v8:5632
LOG=Y

Review-Url: https://codereview.chromium.org/2501873003
Cr-Commit-Position: refs/heads/master@{#41011}

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.org
CC=jgruber@chromium.org

Review-Url: https://codereview.chromium.org/2493823003
Cr-Commit-Position: refs/heads/master@{#41004}

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}

R=mlippautz@chromium.org

Review-Url: https://codereview.chromium.org/2498633002
Cr-Commit-Position: refs/heads/master@{#40952}

According to the spec data segments are allowed even if the memory size
is zero. However, if one of the data segments has a length greater than
0, then module instantiation should fail.

I also changed the exception type in LoadDataSegments to TypeError,
because that's the exception type for all exceptions which can happen
during instantiation.

R=titzer@chromium.org, rossberg@chromium.org
TEST=cctest/test-run-wasm-module/EmptyMemoryEmptyDataSegment, cctest/test-run-wasm-module/EmptyMemoryNonEmptyDataSegment

Review-Url: https://codereview.chromium.org/2483053005
Cr-Commit-Position: refs/heads/master@{#40922}