Skip to content

V
V8
Switch branch/tag
  1. 02 Feb, 2017 2 commits
  3. 24 Jan, 2017 1 commit
  5. 20 Jan, 2017 2 commits
  7. 18 Jan, 2017 1 commit
  9. 17 Jan, 2017 1 commit
  11. 15 Jan, 2017 1 commit
  13. 13 Jan, 2017 3 commits
  15. 12 Jan, 2017 4 commits
  17. 09 Jan, 2017 2 commits
  19. 06 Jan, 2017 1 commit
    • mtrofin's avatar
      [wasm] factor lower level utilties out of WasmFullDecoder · ccfb815c
      mtrofin authored 
      Separated:
- decoding of locals
- loop assignment analysis
- determination of opcode length

as statics that work on a Decoder. Neither need the context of a
Module, and were used in scenarios where one wasn't available either.

Changed BodyLocalDecls to match the usecases for the type. In all but
one (a printer), we want the list (in order of declaration, with
repetitions) of types of locals.

Removed a now-unnecessary constructor for the WasmFullDecoder.

BUG=

Review-Url: https://codereview.chromium.org/2610813009
Cr-Commit-Position: refs/heads/master@{#42115}
      ccfb815c
  21. 04 Jan, 2017 1 commit
  23. 21 Dec, 2016 2 commits
  25. 20 Dec, 2016 1 commit
  27. 14 Dec, 2016 1 commit
  29. 30 Nov, 2016 1 commit
    • clemensh's avatar
      [wasm] Remove raw byte pointers from WasmModule · 6572b562
      clemensh authored 
      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}
      6572b562
  31. 11 Nov, 2016 1 commit
  33. 10 Nov, 2016 1 commit
  35. 09 Nov, 2016 3 commits
  37. 08 Nov, 2016 2 commits
  39. 07 Nov, 2016 3 commits
    • machenbach's avatar
      Revert of [wasm] Indirect calls without function table cause validation... · 32ec567d
      machenbach authored 
      Revert of [wasm] Indirect calls without function table cause validation errors. (patchset #3 id:40001 of https://codereview.chromium.org/2484623002/ )

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}
      32ec567d
    • ahaas's avatar
      [wasm] Indirect calls without function table cause validation errors. · 3de52047
      ahaas authored 
      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

Review-Url: https://codereview.chromium.org/2484623002
Cr-Commit-Position: refs/heads/master@{#40802}
      3de52047
    • ahaas's avatar
      [wasm] Compare the maximum memory size with the spec limit, not with the V8 limit · 15d4984b
      ahaas authored 
      The maximum memory size is a user-defined upper limit for the size of
the memory of a WebAssembly instance. The actual limit is the minimum of
the user-defined limit and the V8 limit. With this CL we allow the
user-defined limit to be greater than the V8 limit, which is required by
the spec.

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

TEST=unittests/WasmModuleVerifyTest.MaxMaximumMemorySize

Review-Url: https://codereview.chromium.org/2484643002
Cr-Commit-Position: refs/heads/master@{#40801}
      15d4984b
  41. 29 Oct, 2016 1 commit
  43. 28 Oct, 2016 2 commits
  45. 26 Oct, 2016 1 commit
  47. 25 Oct, 2016 1 commit
  49. 19 Oct, 2016 1 commit
    • titzer's avatar
      [wasm] Use a Managed<WasmModule> to hold metadata about modules. · 418b239f
      titzer authored 
      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}
      418b239f