1. 06 Apr, 2017 1 commit
  2. 23 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Implement indirect function calls · b8f88601
      Clemens Hammacher authored
      This CL adds support for indirect function calls to the interpreter. It
      can indirectly call other wasm function in the same instance, which are
      then executed in the interpreter, or call imported functions.
      
      Implementing this required some refactoring:
      - The wasm interpreter now unwraps import wrappers on demand, instead
        of unwrapping all of them on instantiation and storing a vector of
        handles. This also avoids the DeferredHandleScope completely, instead
        we just store two global handles in the code map.
      - The interpreter gets the code table, function tables and signature
        tables directly from the attached wasm instance object. This ensures
        that the interpreter sees all updates to tables that might have been
        performed by external code.
      - There is now common functionality for calling a code object. This is
        used for direct calls to imported functions and for all indirect
        calls. As these code objects can also be wasm functions which should
        be executed in the interpreter itself, I introduce a struct to hold
        the outcome of calling the code object, or a pointer to
        InterpreterCode to be called in the interpreter.
      
      R=ahaas@chromium.org
      BUG=v8:5822
      
      Change-Id: I20fb2ea007e79e5fcff9afb4b1ca31739ebcb83f
      Reviewed-on: https://chromium-review.googlesource.com/458417
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44059}
      b8f88601
  3. 21 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Allow different activations · 3214ccf3
      Clemens Hammacher authored
      This CL makes the interpreter reentrant by allowing different
      activations to be live at the same time. The wasm interpreter keeps a
      list of activations and stores the stack height at the start of each
      activation. This information is used to unwind just one activation, or
      show the right portion of the interpreter stack for each interpreter
      entry frame.
      The WasmDebugInfo object stores a mapping from frame pointer (of the
      interpreter entry) to the activation id in order to identify the
      activation based on the physical interpreter entry frame.
      
      R=titzer@chromium.org, ahaas@chromium.org
      BUG=v8:5822
      
      Change-Id: Ibbf93f077f907213173a92e0a2f7f3556515e8eb
      Reviewed-on: https://chromium-review.googlesource.com/453958
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43976}
      3214ccf3
  4. 20 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Handle stack unwinding · 91852dff
      Clemens Hammacher authored
      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: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43937}
      91852dff
  5. 16 Mar, 2017 2 commits
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Throw exception on trap · 783f68c5
      Clemens Hammacher authored
      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: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43859}
      783f68c5
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Implement calling imported functions · f3aeb762
      Clemens Hammacher authored
      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: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43855}
      f3aeb762
  6. 14 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Cleanup wasm interpreter · 0a4c5c44
      Clemens Hammacher authored
      This is a cleanup in preparation to implement calling imported
      functions via the wasm interpreter.
      For imported functions, we do not create entries in the
      interpreter_code_ vector any more.
      
      I also simplified the interface and removed unused or redundant return
      values. More things are now DCHECKed instead of bailing out.
      
      Also, we previously had two PushFrame methods: One is supposed to
      initialize the interpreter from external code (i.e. adds the first
      frame to the stack), the other one is used to push new frames on the
      frame stack for called functions. This CL renames the first to
      InitFrame, and makes it use the second one. The other remaining user is
      the DoCall method.
      
      R=titzer@chromium.org
      BUG=v8:5822
      
      Change-Id: Id09ff1e3256428fbd8c955e4664507a0c3167e53
      Reviewed-on: https://chromium-review.googlesource.com/453482
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43793}
      0a4c5c44
  7. 21 Feb, 2017 1 commit
  8. 24 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Implement stepping in wasm code · 3dea55b4
      clemensh authored
      Implement stepping by remembering the current step action in the wasm
      interpreter handle in WasmDebugInfo, and using it when continuing
      execution in the interpreter.
      The control flow is as follows: After module compilation, the user sets
      a breakpoint in wasm. The respective function is redirected to the
      interpreter and the breakpoint is set on the interpreter. When it is
      hit, we notify all debug event listeners, which might prepare stepping.
      When returning from these listeners, before continuing execution, we
      check whether stepping was requested and continue execution in the
      interpreter accordingly.
      
      Stepping from Wasm to JS and vice versa will be implemented and tested
      in a follow-up CL. Testing this requires breakpoints and stepping in
      Wasm to be exposed via the inspector interface, such that we can write
      an inspector test. This mixed JS-Wasm-execution is hard to set up in a
      cctest.
      
      R=titzer@chromium.org, yangguo@chromium.org
      BUG=
      
      Review-Url: https://codereview.chromium.org/2649533002
      Cr-Commit-Position: refs/heads/master@{#42624}
      3dea55b4
  9. 20 Jan, 2017 2 commits
  10. 19 Jan, 2017 2 commits
  11. 18 Jan, 2017 2 commits
    • clemensh's avatar
      [wasm] Improve pimpl implementation in WasmInterpreter::Thread · 4f91cee3
      clemensh authored
      As no one will ever try to allocate a Thread directly, we can just make
      Thread a proxy of ThreadImpl by reinterpret_casting between both types.
      This allows to not mention ThreadImpl in the header at all, and to
      define it in an anonymous namespace in the implementation, allowing for
      more optimizations.
      It also saves runtime, as no memory load is needed to forward from
      Thread to ThreadImpl, and we do not need to allocate ThreadImpl objects
      on the heap.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2643443002
      Cr-Commit-Position: refs/heads/master@{#42450}
      4f91cee3
    • clemensh's avatar
      [wasm] Use pimpl idiom for interpreter thread implementation · 7634b0eb
      clemensh authored
      We used dynamic dispatch before, which has considerable runtime
      overhead. Pimpl (a.k.a. opaque pointer) has the same memory overhead
      of one additional pointer, but less runtime overhead.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2639013002
      Cr-Commit-Position: refs/heads/master@{#42442}
      7634b0eb
  12. 21 Dec, 2016 1 commit
  13. 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
  14. 20 Oct, 2016 1 commit
    • ahaas's avatar
      [wasm] Track in the interpreter if a NaN could have been produced. · 57b14b06
      ahaas authored
      The wasm specification does not fully specify the binary representation
      of NaN: the sign bit can be non-deterministic. The wasm-code fuzzer
      found a test case where the wasm interpreter and the compiled code
      produce a different sign bit for a NaN, and as a consequence they
      produce different results.
      
      With this CL the interpreter tracks whether it executed an instruction
      which can produce a NaN, which are div and sqrt instructions. The
      fuzzer uses this information and compares the result of the interpreter
      with the result of the compiled code only if there was no instruction
      which could have produced a NaN.
      
      R=titzer@chromium.org
      
      TEST=cctest/test-run-wasm-interpreter/TestMayProduceNaN
      BUG=chromium:657481
      
      Review-Url: https://chromiumcodereview.appspot.com/2438603003
      Cr-Commit-Position: refs/heads/master@{#40474}
      57b14b06
  15. 12 Oct, 2016 1 commit
  16. 27 Sep, 2016 1 commit
    • titzer's avatar
      [wasm] Master CL for Binary 0xC changes. · 28392ab1
      titzer authored
      [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}
      28392ab1
  17. 26 Sep, 2016 1 commit
    • jgruber's avatar
      Enable component builds for fuzzers · 22606f0c
      jgruber authored
      V8 is collecting a growing amount of fuzzers, all of which take substantial
      space on the bots and in chromium build archives. This CL improves that
      situation by allowing component (shared library) builds for almost all fuzzers.
      
      The parser fuzzer is handled as an exception since it would require exporting a
      large number of additional functions.
      
      A component build results in about a 50-100x improvement in file size for each
      fuzzer (~50M-100M to around 1.1M).
      
      BUG=chromium:648864
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
      
      Review-Url: https://codereview.chromium.org/2360983002
      Cr-Commit-Position: refs/heads/master@{#39709}
      22606f0c
  18. 23 Sep, 2016 2 commits
    • machenbach's avatar
      Revert of [wasm] Master CL for Binary 0xC changes. (patchset #26 id:490001 of... · e1eee748
      machenbach authored
      Revert of [wasm] Master CL for Binary 0xC changes. (patchset #26 id:490001 of https://codereview.chromium.org/2345593003/ )
      
      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}
      e1eee748
    • titzer's avatar
      [wasm] Master CL for Binary 0xC changes. · 76eb976a
      titzer authored
      [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}
      76eb976a
  19. 20 Sep, 2016 1 commit
  20. 09 Jun, 2016 1 commit
  21. 30 May, 2016 1 commit
  22. 25 May, 2016 1 commit
    • titzer's avatar
      [wasm] Implement an interpreter for WASM. · e4bb7ff9
      titzer authored
      This interpreter directly decodes and executes WASM binary code for
      the purpose of supporting low-level debugging. It is not currently
      integrated into the main WASM implementation.
      
      R=ahaas@chromium.org,clemensh@chromium.org,rossberg@chromium.org,binji@chromium.org
      BUG=
      
      Review-Url: https://codereview.chromium.org/1972153002
      Cr-Commit-Position: refs/heads/master@{#36497}
      e4bb7ff9