- 05 Apr, 2017 1 commit
-
-
Michael Starzinger authored
This extends the test coverage for source position tracking of ToNumber conversion to also test conversion to "double" type. It also fixes the discovered inconsistencies. Note that the conversion to "float" remains untested as imported functions are not allowed have "float" return type. R=clemensh@chromium.org TEST=mjsunit/wasm/asm-wasm-exception-in-tonumber BUG=v8:6127 Change-Id: I6c59b7a24456a585a814f19a86eb9447ac5098ab Reviewed-on: https://chromium-review.googlesource.com/467251 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#44409}
-
- 12 Dec, 2016 1 commit
-
-
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}
-
- 09 Dec, 2016 1 commit
-
-
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}
-
- 08 Dec, 2016 2 commits
-
-
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}
-
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}
-