1. 05 Apr, 2017 1 commit
  2. 12 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Provide correct eval origin for asm.js code · c4057d46
      clemensh authored
      This CL moves all methods related to scripts and eval origin (HasScript,
      GetScript, IsEval, GetEvalOrigin) from JSStackFrame to StackFrameBase,
      because it also applies to WasmFrames.
      This makes the AppendFileLocation method append the same information to
      WasmStackFrames and AsmJsWasmStackFrames than to JSStackFrames.
      
      R=titzer@chromium.org, mstarzinger@chromium.org
      BUG=v8:4203
      
      Review-Url: https://codereview.chromium.org/2557923005
      Cr-Commit-Position: refs/heads/master@{#41642}
      c4057d46
  3. 09 Dec, 2016 1 commit
    • 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
  4. 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