1. 05 Apr, 2017 1 commit
  2. 31 Mar, 2017 2 commits
  3. 29 Mar, 2017 1 commit
    • mtrofin's avatar
      [wasm] Fix serialization after instantiation · f2531acb
      mtrofin authored
      The regression comes from attempting to serialize a module with memory
      requirements after instantiation - which is what happens in common emscripten
      scenarios, where the module is obtained from WebAssembly.instantiate(buffer). We then try and serialize the JSArrayBuffer
      representing the instance memory. That operation fails.
      
      Added regression test and also extended the test to cover the other 2
      instance-specific values - globals and tables.
      
      Added a discussion on WasmCompiledModule (comments) explaining design decisions.
      
      BUG=chromium:705562
      
      Review-Url: https://codereview.chromium.org/2784453002
      Cr-Commit-Position: refs/heads/master@{#44250}
      f2531acb
  4. 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
  5. 20 Mar, 2017 3 commits
    • Clemens Hammacher's avatar
      [wasm] For wasm-interpret-all: Iterate code only once for patching · 1f617767
      Clemens Hammacher authored
      Before, we were redirecting each function to the interpreter by iterating all
      code and patching all call sites using this one function. The runtime was
      hence quadratic if all functions were redirected to the interpreter as
      done by the --wasm-interpret-all flag.
      This CL fixes this to only iterate the code once and redirecting an
      arbitrary number of function.
      
      R=ahaas@chromium.org, titzer@chromium.org
      BUG=v8:5822
      
      Change-Id: Ia4f2e94a2468f9bef3035b599e1f8a18acf309da
      Reviewed-on: https://chromium-review.googlesource.com/455785
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43946}
      1f617767
    • 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
    • Clemens Hammacher's avatar
      [wasm] Lazy compilation for asm.js · 4f3e168c
      Clemens Hammacher authored
      This CL adds general lazy compilation support to WebAssembly, according
      to the design described in the design doc (see referenced bug).
      
      It's not used currently, but I tested locally that all tests succeed if
      I enable it by default.
      
      With a later CL, we will enable lazy compilation by default for
      validate-asm: https://chromium-review.googlesource.com/451318
      
      R=titzer@chromium.org, ahaas@chromium.org, bmeurer@chromium.org
      BUG=v8:5991
      
      Change-Id: I85440382118a24fc245e78a5a90cf2b95659cd69
      Reviewed-on: https://chromium-review.googlesource.com/451317
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43936}
      4f3e168c
  6. 17 Mar, 2017 2 commits
  7. 16 Mar, 2017 1 commit
  8. 07 Mar, 2017 1 commit
  9. 06 Mar, 2017 1 commit
  10. 21 Feb, 2017 2 commits
    • clemensh's avatar
      [wasm] Test argument passing in the interpreter entry · e6819ee2
      clemensh authored
      Test the wasm interpreter entry stub by creating two wasm functions A
      and B, make A pass arguments to B, then redirect B to be executed in the
      interpreter.
      Test different number and types or arguments.
      
      BUG=v8:5822
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2651793003
      Cr-Commit-Position: refs/heads/master@{#43353}
      e6819ee2
    • mtrofin's avatar
      [wasm] Managed<T> ensures T's lifetime does not leak past Isolate's · caa1d4b2
      mtrofin authored
      Native resources allocated by v8, as internal implementation detail,
      and held by a Foreign object, must be released when the Isolate is
      torn down. Example: wasm::WasmModule allocated by wasm compile, and
      held throughout the lifetime of the WebAssembly.Module object.
      
      This change:
      - Extends Managed<CppType> with a mechanism for doing just that
      - Separates the role of Managed<CppType> to be strictly an owner of
      the lifetime of the native resource. For cases where that's not
      desirable, we can polymorphically use Foregin.
      - moves managed.h out of wasm, since it's not wasm-specific.
      
      BUG=680065
      
      Review-Url: https://codereview.chromium.org/2676513008
      Cr-Commit-Position: refs/heads/master@{#43350}
      caa1d4b2
  11. 14 Feb, 2017 1 commit
  12. 13 Feb, 2017 1 commit
  13. 24 Jan, 2017 2 commits
    • 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
    • titzer's avatar
      [wasm] Do not patch memory references in imported functions. · e9b22dde
      titzer authored
      BUG=v8:5860
      R=rossberg@chromium.org
      
      Review-Url: https://codereview.chromium.org/2653533003
      Cr-Commit-Position: refs/heads/master@{#42622}
      e9b22dde
  14. 20 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Implement frame inspection for interpreted frames · 09525c8f
      clemensh authored
      Frame inspection is currently limited to locations of execution.
      Further details like local variables or stack content will follow later.
      
      The FrameInspector now stores a pointer to the interpreted wasm frame,
      and redirects certain requests there, just as for deoptimized frames.
      Hitting breakpoints is now also supported for wasm frames.
      
      R=yangguo@chromium.org, titzer@chromium.org
      BUG=v8:5822
      
      Review-Url: https://codereview.chromium.org/2629823003
      Cr-Commit-Position: refs/heads/master@{#42551}
      09525c8f
  15. 18 Jan, 2017 2 commits
    • clemensh's avatar
      [wasm] Skip serialization of breakpoints and certion stubs · 3c897883
      clemensh authored
      Breakpoints are always re-set by the embedder after compilation, so we
      don't want to store the corresponding breakpoint objects.
      Also don't serialize WASM_INTERPRETER_ENTRY stubs as they are replaced
      by ordinary WASM_FUNCTION code at instantiation anyway, and skip
      WASM_TO_JS wrappers which are recompiled on each instantiation.
      Instead, we serialize the Illegal builtin, and also use that one
      instead of the placeholder when compiling the wasm code initially.
      
      R=titzer@chromium.org, yangguo@chromium.org
      BUG=v8:5822
      
      Review-Url: https://codereview.chromium.org/2629853004
      Cr-Commit-Position: refs/heads/master@{#42451}
      3c897883
    • clemensh's avatar
      [wasm] Set and store breakpoints in wasm · 2f3de27e
      clemensh authored
      Store breakpoint positions in the WasmSharedModuleData in order to set
      them on new instantiations. Also redirect them to all live instances at
      the time the breakpoint is set.
      
      Inside the WasmDebugInfo, we store the BreakPointInfo objects to find
      hit breakpoints.
      
      R=titzer@chromium.org, yangguo@chromium.org
      BUG=v8:5822
      
      Review-Url: https://codereview.chromium.org/2626253002
      Cr-Commit-Position: refs/heads/master@{#42443}
      2f3de27e
  16. 17 Jan, 2017 1 commit
  17. 15 Jan, 2017 1 commit
  18. 13 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Instantiate the interpreter on demand · eb04a25f
      clemensh authored
      If a breakpoint is set on a wasm function, compile an interpreter entry
      stub for it, and replace all calls to the original function by calls to
      this interpreter entry.
      Also, instantiate a wasm interpreter object on demand and set the
      breakpoint there.
      
      R=titzer@chromium.org
      BUG=v8:5822
      
      Review-Url: https://codereview.chromium.org/2625093004
      Cr-Commit-Position: refs/heads/master@{#42309}
      eb04a25f
  19. 12 Jan, 2017 1 commit
    • clemensh's avatar
      Refactor FrameSummary for JS and Wasm frames · df5417ae
      clemensh authored
      Wasm frames can be either compiled or interpreted. For interpreted wasm
      frames, there is only one physical stack frame representing an
      arbitrary stack of interpreted functions. Hence the physical stack
      frame needs to provide a summary of the underlying functions.
      Summaries were tailored for JavaScript frames before. Now they are
      universal.
      
      The refactored FrameSummaries are now also used in the FrameInspector,
      and from the StackFrame objects themselves, to avoid code duplication.
      
      All dispatch is implemented "manually", making the FrameSummary still
      stack-allocatable.
      
      BUG=v8:5822
      R=yangguo@chromium.org, titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2619353006
      Cr-Commit-Position: refs/heads/master@{#42279}
      df5417ae
  20. 11 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Add support for compiling WASM_INTERPRETER_ENTRY stubs · a2efde46
      clemensh authored
      Also, add a runtime function to call the interpreter, passing a
      stack-allocated buffer holding the arguments.
      The WASM_INTERPRETER_ENTRY stub allocates the stack slot for the
      arguments, fills it, and calls to the wasm interpreter.
      It's abi is compatible with WASM functions, such that we can just
      replace a call to a WASM_FUNCTION with a call to
      WASM_INTERPRETER_ENTRY.
      See tracking bug to get the overall picture.
      
      BUG=v8:5822
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2619803004
      Cr-Commit-Position: refs/heads/master@{#42242}
      a2efde46
  21. 10 Jan, 2017 1 commit
  22. 20 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Introduce WasmSharedModuleData and refactor other objects · 081ac370
      clemensh authored
      The new object will hold information which is shared by all clones of a
      WasmCompiledModule, e.g. the decoded asm.js offset table, and in the
      future also breakpoints. From there, we can set them on each new
      instantiation of any clone.
      
      While already changing lots of the code base, I also renamed all
      getters from "get_foo" to "foo", to conform to the style guide.
      
      R=titzer@chromium.org, yangguo@chromium.org
      BUG=v8:5732
      
      Review-Url: https://codereview.chromium.org/2591653002
      Cr-Commit-Position: refs/heads/master@{#41862}
      081ac370
  23. 19 Dec, 2016 2 commits
    • clemensh's avatar
      [wasm] Implement GetPossibleBreakpoints · 1fef739a
      clemensh authored
      This CL implements GetPossibleBreakpoints for wasm, by iterating over
      all functions in the requested range and returning the location of all
      instructions within that range.
      
      The connection to the inspector will be added later, when setting
      breakpoint also works for wasm: http://crrev.com/2536763002
      
      BUG=chromium:613110
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2588763002
      Cr-Commit-Position: refs/heads/master@{#41818}
      1fef739a
    • clemensh's avatar
      [wasm] Always provide a wasm instance object at runtime · 21a85c4a
      clemensh authored
      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.org
      CC=jgruber@chromium.org
      BUG=v8:5620
      
      Review-Url: https://codereview.chromium.org/2551053002
      Cr-Commit-Position: refs/heads/master@{#41809}
      21a85c4a
  24. 09 Dec, 2016 2 commits
    • clemensh's avatar
      [wasm] Remove declared but undefined methods · 0868b76b
      clemensh authored
      We should really think about having a static analysis to check for
      such errors, and a bot executing it regularly.
      This is not the first time I encounter declared functions that are
      never defined.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2561333002
      Cr-Commit-Position: refs/heads/master@{#41617}
      0868b76b
    • clemensh's avatar
      [wasm] Fix location for error in asm.js ToNumber conversion · 890d28f3
      clemensh authored
      In the asm.js code translated to wasm, we call imported functions via a
      WASM_TO_JS stub, which first calls the function and then calls ToNumber
      on the return value. Exceptions can happen in both calls.
      We were only ever reporting the location of the function call, whereas
      asm.js code executed via turbofan reported the location of the type
      coercion operator ("+" on "+foo()" or "|" on "foo()|0").
      
      This CL implements the same behaviour for asm.js code translated to
      wasm. The following is changed:
      - the AsmWasmBuilder records the parent node when descending on a binary
        operator (also "+foo()" is represented by a binary operation).
      - it stores not one location per call in the source position side
        table, but two (one for the call, one for the parent which does the
        type coercion).
      - the wasm compiler annotates the source positions "0" and "1" to the
        two calls in the WASM_TO_JS wrapper (only if the module origin is
        asm.js).
      - the StackFrame::State struct now also holds the callee_pc_address,
        which is set in ComputeCallerState. The WASM frame uses this
        information to determine whether the callee frame is WASM_TO_JS, and
        whether that frame is at the ToNumber conversion call.
      - the same information is also stored in the FrameArray which is used
        to reconstruct the stack trace later.
      
      R=titzer@chromium.org, bradnelson@chromium.org
      CC=jgruber@chromium.org
      BUG=v8:4203,v8:5724
      
      Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
      Review-Url: https://codereview.chromium.org/2555243002
      Cr-Original-Commit-Position: refs/heads/master@{#41599}
      Cr-Commit-Position: refs/heads/master@{#41613}
      890d28f3
  25. 08 Dec, 2016 2 commits
    • clemensh's avatar
      Revert of [wasm] Fix location for error in asm.js ToNumber conversion... · d3d12541
      clemensh authored
      Revert of [wasm] Fix location for error in asm.js ToNumber conversion (patchset #5 id:80001 of https://codereview.chromium.org/2555243002/ )
      
      Reason for revert:
      gc-stress failures
      
      Original issue's description:
      > [wasm] Fix location for error in asm.js ToNumber conversion
      >
      > In the asm.js code translated to wasm, we call imported functions via a
      > WASM_TO_JS stub, which first calls the function and then calls ToNumber
      > on the return value. Exceptions can happen in both calls.
      > We were only ever reporting the location of the function call, whereas
      > asm.js code executed via turbofan reported the location of the type
      > coercion operator ("+" on "+foo()" or "|" on "foo()|0").
      >
      > This CL implements the same behaviour for asm.js code translated to
      > wasm. The following is changed:
      > - the AsmWasmBuilder records the parent node when descending on a binary
      >   operator (also "+foo()" is represented by a binary operation).
      > - it stores not one location per call in the source position side
      >   table, but two (one for the call, one for the parent which does the
      >   type coercion).
      > - the wasm compiler annotates the source positions "0" and "1" to the
      >   two calls in the WASM_TO_JS wrapper (only if the module origin is
      >   asm.js).
      > - during stack trace generation (in the StackTraceIterator), when we
      >   move from the WASM_TO_JS frame to the WASM frame, we remember at which
      >   call inside the WASM_TO_JS wrapper we are, and encode this information
      >   in the generated caller state, used for the WASM frame.
      > - the same information is also stored in the FrameArray which is used
      >   to reconstruct the stack trace later.
      >
      > R=titzer@chromium.org, bradnelson@chromium.org
      > CC=jgruber@chromium.org
      > BUG=v8:4203,v8:5724
      >
      > Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
      > Cr-Commit-Position: refs/heads/master@{#41599}
      
      TBR=bradnelson@chromium.org,mstarzinger@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:4203,v8:5724
      
      Review-Url: https://codereview.chromium.org/2563613003
      Cr-Commit-Position: refs/heads/master@{#41601}
      d3d12541
    • clemensh's avatar
      [wasm] Fix location for error in asm.js ToNumber conversion · 94cd46b5
      clemensh authored
      In the asm.js code translated to wasm, we call imported functions via a
      WASM_TO_JS stub, which first calls the function and then calls ToNumber
      on the return value. Exceptions can happen in both calls.
      We were only ever reporting the location of the function call, whereas
      asm.js code executed via turbofan reported the location of the type
      coercion operator ("+" on "+foo()" or "|" on "foo()|0").
      
      This CL implements the same behaviour for asm.js code translated to
      wasm. The following is changed:
      - the AsmWasmBuilder records the parent node when descending on a binary
        operator (also "+foo()" is represented by a binary operation).
      - it stores not one location per call in the source position side
        table, but two (one for the call, one for the parent which does the
        type coercion).
      - the wasm compiler annotates the source positions "0" and "1" to the
        two calls in the WASM_TO_JS wrapper (only if the module origin is
        asm.js).
      - during stack trace generation (in the StackTraceIterator), when we
        move from the WASM_TO_JS frame to the WASM frame, we remember at which
        call inside the WASM_TO_JS wrapper we are, and encode this information
        in the generated caller state, used for the WASM frame.
      - the same information is also stored in the FrameArray which is used
        to reconstruct the stack trace later.
      
      R=titzer@chromium.org, bradnelson@chromium.org
      CC=jgruber@chromium.org
      BUG=v8:4203,v8:5724
      
      Review-Url: https://codereview.chromium.org/2555243002
      Cr-Commit-Position: refs/heads/master@{#41599}
      94cd46b5
  26. 06 Dec, 2016 1 commit
  27. 05 Dec, 2016 1 commit
    • clemensh's avatar
      [inspector] Split off interface-types.h · f5fb2da6
      clemensh authored
      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}
      f5fb2da6
  28. 01 Dec, 2016 1 commit
  29. 30 Nov, 2016 1 commit
  30. 28 Nov, 2016 1 commit
    • clemensh's avatar
      [wasm] Move asm.js offset table to compiled module · 916a5337
      clemensh authored
      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}
      916a5337