1. 10 May, 2019 1 commit
  2. 27 Mar, 2019 1 commit
  3. 21 Mar, 2019 1 commit
    • Ben Smith's avatar
      [wasm] Call through dispatch table in interpreter · 1a88414c
      Ben Smith authored
      When running wasm tests, the interpreter previously used a static
      collection of function indexes stored in WasmTable to perform
      call_indirect calls internal to that module. This has the wrong behavior
      if the table is changed (via WasmTableObject::Set, `table.copy`, or
      `table.init`).
      
      This CL changes the cctests to always generate an intepreter entry for
      all functions, and stores those entries in the dispatch table. This
      allows us to use the same execution path as for non-testing code.
      
      The interpreter entry compiler needed to be changed to support
      multi-value returns too, since a 64-bit integer return value may be
      lowered to two 32-bit integer returns.
      
      Bug: v8:9016
      Change-Id: I277df21ffde5c2eee0b691fcc9bab2b1a43eeffc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1531137
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60380}
      1a88414c
  4. 12 Mar, 2019 1 commit
  5. 07 Feb, 2019 1 commit
  6. 03 Oct, 2018 1 commit
    • Hans Wennborg's avatar
      Fix -Wdefaulted-function-deleted warnings · cb8d93e1
      Hans Wennborg authored
      This is part of clean-up for a new Clang warning that we'd like to
      enable. This patch addresses all warnings from V8 that I saw in a full debug
      build of Chromium on Linux.
      
      ../../v8/src/reloc-info.h:405:18: warning: explicitly defaulted move assignment
      operator is implicitly deleted [-Wdefaulted-function-deleted]
        RelocIterator& operator=(RelocIterator&&) = default;
                       ^
      ../../v8/src/reloc-info.h:447:13: note: move assignment operator of
      'RelocIterator' is implicitly deleted because field 'mode_mask_' is of
      const-qualified type 'const int'
        const int mode_mask_;
                  ^
      
      ../../v8/src/wasm/baseline/liftoff-compiler.cc:111:36: warning: explicitly
      defaulted move constructor is implicitly deleted [-Wdefaulted-function-deleted]
        MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(LiftoffCompiler);
                                         ^
      ../../v8/src/wasm/baseline/liftoff-compiler.cc:1834:20: note: move constructor
      of 'LiftoffCompiler' is implicitly deleted because field 'asm_' has a deleted
      move constructor
        LiftoffAssembler asm_;
                         ^
      
      ../../v8/src/wasm/wasm-debug.cc:95:3: warning: explicitly defaulted move
      assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
        MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(InterpreterHandle);
        ^
      ../../v8/src/wasm/wasm-debug.cc:98:19: note: move assignment operator of
      'InterpreterHandle' is implicitly deleted because field 'interpreter_' has a
      deleted move assignment operator
        WasmInterpreter interpreter_;
                        ^
      ../../v8/src/wasm/wasm-interpreter.h:211:35: note: copy assignment operator of
      'WasmInterpreter' is implicitly deleted because field 'internals_' is of
      const-qualified type 'v8::internal::wasm::WasmInterpreterInternals *const'
        WasmInterpreterInternals* const internals_;
                                        ^
      
      Bug: chromium:890307
      Change-Id: Idfc5827f24821212081a006c4329c466c4576bcc
      Reviewed-on: https://chromium-review.googlesource.com/c/1256863
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56351}
      cb8d93e1
  7. 05 Jul, 2018 1 commit
  8. 02 May, 2018 1 commit
  9. 06 Apr, 2018 1 commit
  10. 04 Apr, 2018 2 commits
    • Ben Titzer's avatar
      Revert "[wasm] Merge the WasmContext into WasmInstanceObject" · 8adb94fc
      Ben Titzer authored
      This reverts commit 57bf0bfe.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > [wasm] Merge the WasmContext into WasmInstanceObject
      > 
      > This change makes lifetime management of WasmCode much simpler.
      > By using the WasmInstanceObject as the context for WASM code execution,
      > including the pointer to the memory base and indirect function tables,
      > this keeps the instance alive when WASM code is on the stack, since
      > the instance object is passed as a parameter and spilled onto the stack.
      > This is in preparation of sharing the code between instances and
      > isolates.
      > 
      > Bug: v8:7424
      > 
      > Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
      > Reviewed-on: https://chromium-review.googlesource.com/958520
      > Commit-Queue: Ben Titzer <titzer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52361}
      
      TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7424
      Reviewed-on: https://chromium-review.googlesource.com/995418Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52364}
      8adb94fc
    • Ben L. Titzer's avatar
      [wasm] Merge the WasmContext into WasmInstanceObject · 57bf0bfe
      Ben L. Titzer authored
      This change makes lifetime management of WasmCode much simpler.
      By using the WasmInstanceObject as the context for WASM code execution,
      including the pointer to the memory base and indirect function tables,
      this keeps the instance alive when WASM code is on the stack, since
      the instance object is passed as a parameter and spilled onto the stack.
      This is in preparation of sharing the code between instances and
      isolates.
      
      Bug: v8:7424
      
      Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
      Reviewed-on: https://chromium-review.googlesource.com/958520
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52361}
      57bf0bfe
  11. 21 Feb, 2018 1 commit
  12. 02 Feb, 2018 1 commit
  13. 20 Dec, 2017 1 commit
  14. 16 Oct, 2017 1 commit
  15. 07 Aug, 2017 1 commit
    • Mircea Trofin's avatar
      [wasm] Clarify source of runtime information for interpreter. · 3f1e32b3
      Mircea Trofin authored
      This is part of the effort to consolidate the ownership of
      wasm instantiation/specialization parameters.
      
      This change is focused solely on the interpreter part of that effort, to
      verify we're not regressing performance in interpreter benchmarks.
      
      There are two aspects being addressed:
      - dataflow-wise, we always fetch the interpreter's memory view from the
      runtime objects (i.e. WasmInstanceObject/WasmCompiledModule). This is
      consistent with how other instance-specific information is obtained
      (e.g. code, indirect functions).
      
      - representation-wise, we do not reuse ModuleEnv/WasmInstance just for
      the memory view, because it is surprising that other instance info isn't
      accessed from there. 
      
      Bug: 
      Change-Id: I536fbffd8e1f142a315fa1770ba9b08319f56a8e
      Reviewed-on: https://chromium-review.googlesource.com/602083Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47205}
      3f1e32b3
  16. 18 Jul, 2017 1 commit
  17. 14 Jul, 2017 1 commit
    • Clemens Hammacher's avatar
      Reland "[wasm] Don't store global handles in the interpreter" · b53141ec
      Clemens Hammacher authored
      This is a reland of 5648aad5.
      Previous compile error should be fixed by disabling strict aliasing
      assumptions on gyp: https://chromium-review.googlesource.com/c/571806
      
      Original change's description:
      > [wasm] Don't store global handles in the interpreter
      > 
      > Storing global handles in the interpreter is dangerous, because the
      > global handles are strong roots into the heap. The interpreter itself is
      > referenced from the heap via a Managed. Hence the interpreter keeps the
      > instance alive, while the instance keeps the Managed alive. So the GC
      > will never collect them.
      > 
      > This CL refactors this to only store the handle to the instance object
      > while executing in the interpreter, and clearing it when returning.
      > It also removes the cache of import wrappers, as it should not be
      > performance critical, but keeps lots of objects alive. If it turns out
      > to be performance critical, we will have to reintroduce such a cache
      > stored in the WasmDebugInfo object.
      > 
      > R=titzer@chromium.org
      > CC=ahaas@chromium.org
      > 
      > Bug: chromium:610330
      > Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
      > Reviewed-on: https://chromium-review.googlesource.com/567058
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46629}
      
      TBR=titzer@chromium.org
      
      Bug: chromium:610330
      Change-Id: Ic7836b1b1a044a89f2138f0c76f92acd3a1b2f2b
      Reviewed-on: https://chromium-review.googlesource.com/570578
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46679}
      b53141ec
  18. 13 Jul, 2017 2 commits
    • Clemens Hammacher's avatar
      Revert "[wasm] Don't store global handles in the interpreter" · 199a26f7
      Clemens Hammacher authored
      This reverts commit 5648aad5.
      
      Reason for revert: Compile error on mips:
      https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/10732
      
      Original change's description:
      > [wasm] Don't store global handles in the interpreter
      > 
      > Storing global handles in the interpreter is dangerous, because the
      > global handles are strong roots into the heap. The interpreter itself is
      > referenced from the heap via a Managed. Hence the interpreter keeps the
      > instance alive, while the instance keeps the Managed alive. So the GC
      > will never collect them.
      > 
      > This CL refactors this to only store the handle to the instance object
      > while executing in the interpreter, and clearing it when returning.
      > It also removes the cache of import wrappers, as it should not be
      > performance critical, but keeps lots of objects alive. If it turns out
      > to be performance critical, we will have to reintroduce such a cache
      > stored in the WasmDebugInfo object.
      > 
      > R=​titzer@chromium.org
      > CC=ahaas@chromium.org
      > 
      > Bug: chromium:610330
      > Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
      > Reviewed-on: https://chromium-review.googlesource.com/567058
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46629}
      
      TBR=titzer@chromium.org,clemensh@chromium.org
      
      Change-Id: Ifadfb885f937f37bb3eab4732a97f20ff40c2583
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:610330
      Reviewed-on: https://chromium-review.googlesource.com/569962Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46630}
      199a26f7
    • Clemens Hammacher's avatar
      [wasm] Don't store global handles in the interpreter · 5648aad5
      Clemens Hammacher authored
      Storing global handles in the interpreter is dangerous, because the
      global handles are strong roots into the heap. The interpreter itself is
      referenced from the heap via a Managed. Hence the interpreter keeps the
      instance alive, while the instance keeps the Managed alive. So the GC
      will never collect them.
      
      This CL refactors this to only store the handle to the instance object
      while executing in the interpreter, and clearing it when returning.
      It also removes the cache of import wrappers, as it should not be
      performance critical, but keeps lots of objects alive. If it turns out
      to be performance critical, we will have to reintroduce such a cache
      stored in the WasmDebugInfo object.
      
      R=titzer@chromium.org
      CC=ahaas@chromium.org
      
      Bug: chromium:610330
      Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
      Reviewed-on: https://chromium-review.googlesource.com/567058Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46629}
      5648aad5
  19. 07 Jul, 2017 1 commit
    • titzer's avatar
      [wasm] Introduce instance types for WebAssembly.* objects. · 17001a05
      titzer authored
      This CL refactors the internal representation of JavaScript-exposed
      WebAssembly objects to be more like other such objects in V8. By introducing
      a new instance type for each of the JS-exposed types, we get more robust
      typechecking without using embedder fields (which were previously used
      when these objects where instance type JS_API_OBJECT).
      
      In addition to the new instance types, the subclasses X of JSObject
      (WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
      now have appropriate Is##X() methods on Object and are now robust.
      
      BUG=v8:6547
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2964943002
      Cr-Commit-Position: refs/heads/master@{#46475}
      17001a05
  20. 09 Jun, 2017 1 commit
  21. 22 May, 2017 1 commit
  22. 28 Apr, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Reduce test-specific code · 1a8e7d13
      Clemens Hammacher authored
      This reduces the amount of special paths for testing.
      Setup the memory used for testing exactly the same way as in real world.
      Also, always connect the interpreter to the instance being executed,
      and to the existing WasmInstance struct. This keeps information
      synchronized between interpreter and test runner.
      These changes allow us to execute e.g. GrowMemory from cctests either
      in the interpreter or in compiled code.
      
      R=ahaas@chromium.org
      
      Change-Id: Id4726d061f3cdba789275350f500d769d27d2d63
      Reviewed-on: https://chromium-review.googlesource.com/488561
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44966}
      1a8e7d13
  23. 25 Apr, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Precompute side table for breaks · 92bf8327
      Clemens Hammacher authored
      Instead of dynamically tracking the block nesting, precompute the
      information statically.
      The interpreter was already using a side table to store the pc diff for
      each break, conditional break and others. The information needed to
      adjust the stack was tracked dynamically, however. This CL also
      precomputes this information, as it is statically known.
      Instead of just storing the pc diff in the side table, we now store the
      pc diff, the stack height diff and the arity of the target block.
      
      Local measurements show speedups of 5-6% on average, sometimes >10%.
      
      R=ahaas@chromium.org
      BUG=v8:5822
      
      Change-Id: I986cfa989aabe1488f2ff79ddbfbb28aeffe1452
      Reviewed-on: https://chromium-review.googlesource.com/485482Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44837}
      92bf8327
  24. 12 Apr, 2017 2 commits
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Avoid double parsing of locals · 366f7530
      Clemens Hammacher authored
      The local variables were parsed two times, which in fact doubled the
      amount of local variables allocated for each called function.
      This was costing memory and performance. As the additional local
      variables were never used, we did not recognize this before.
      
      Add a test case for locals and stack values of interpreted frames.
      
      R=ahaas@chromium.org
      BUG=v8:5822
      
      Change-Id: Ie5cb8d8f5441edee6abb46aa6bebef4a033d582b
      Reviewed-on: https://chromium-review.googlesource.com/474749
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44602}
      366f7530
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Refactor and extend InterpretedFrame · 8a6718b1
      Clemens Hammacher authored
      Similar to WasmInterpreter::Thread, we now also use the pimpl idiom for
      InterpretedFrame, hiding the implementation completely in the .cc file.
      This allows us to store just two things per InterpretedFrameImpl: The
      corresponding thread, and the frame index.
      The external interface changes to always return a std::unique_ptr,
      because the object layout is not known via the public interface, hence
      objects cannot be stack allocated. They also cannot be copied or passed
      by value.
      
      The frame inspection interface will be tested after another fix in
      https://chromium-review.googlesource.com/474749.
      
      R=ahaas@chromium.org
      BUG=v8:5822
      
      Change-Id: I7b109da73df745fac97ec72cb0cf4f0ad71e5da9
      Reviewed-on: https://chromium-review.googlesource.com/472887Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44600}
      8a6718b1
  25. 06 Apr, 2017 1 commit
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 21 Feb, 2017 1 commit
  32. 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
  33. 20 Jan, 2017 2 commits
  34. 19 Jan, 2017 2 commits