[wasm] Generate correct locations for error messages

[wasm] Generate correct locations for error messages

The current logic in Isolate::GetLocationFromStackTrace just ignores
wasm frames, making the computed location point to the first javascript
frame, like this:

test.js:17: RuntimeError: divide by zero
module.exports.main();
               ^
RuntimeError: divide by zero
    at main (<WASM>[1]+5)
    at test.js:17:16

This CL not only fixes the location to point to the top-most wasm
frame, but also exposes to the embedder that the script of that location
is a wasm script, allowing for custom printing of wasm locations.
The Shell::ReportException method now checks for this flag, and prints
wasm locations like this:

<WASM>[0]+5: RuntimeError: divide by zero
RuntimeError: divide by zero
    at main (<WASM>[0]+5)
    at test/message/wasm-trap.js:15:16

R=titzer@chromium.org, yangguo@chromium.org
BUG=chromium:613110
Committed: https://crrev.com/222541dff51aba0623edc98bbecb6e1a35d22063
Cr-Commit-Position: refs/heads/master@{#41640}

[Clemens Hammacher, 2016-12-08 15:03:17]

The CQ bit was checked by clemensh@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-08 15:03:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-08 15:32:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-08 15:32:46]

Dry run: This issue passed the CQ dry run.

[Clemens Hammacher, 2016-12-12 09:35:47]

Ping?

[titzer, 2016-12-12 11:51:04]

lgtm

[titzer, 2016-12-12 11:51:33]

https://codereview.chromium.org/2563673002/diff/1/src/d8.cc
File src/d8.cc (right):

https://codereview.chromium.org/2563673002/diff/1/src/d8.cc#newcode1260
src/d8.cc:1260: auto ToCString = [](const v8::String::Utf8Value& value) {
Finally a decent use of C++ lambda!

[Yang, 2016-12-12 11:52:08]

On 2016/12/12 11:51:04, titzer wrote:
> lgtm

lgtm.

[Clemens Hammacher, 2016-12-12 12:05:42]

The CQ bit was checked by clemensh@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-12 12:05:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-12 12:07:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-12 12:07:17]

Dry run: Try jobs failed on following builders:
  v8_linux64_asan_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng/buil...)
  v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)
  v8_linux64_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/17648)
  v8_linux_arm_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng/builds/...)
  v8_linux_dbg_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng/builds/17710)
  v8_linux_gcc_compile_rel on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_gcc_compile_rel/bu...)
  v8_linux_mips64el_compile_rel on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mips64el_compile_r...)
  v8_linux_mipsel_compile_rel on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mipsel_compile_rel...)
  v8_linux_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel_ng/builds/17622)
  v8_presubmit on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/30413)
  v8_win64_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng/builds/19227)
  v8_win_compile_dbg on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win_compile_dbg/builds/2...)
  v8_win_nosnap_shared_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win_nosnap_shared_rel_ng...)
  v8_win_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel_ng/builds/19354)

[Clemens Hammacher, 2016-12-12 12:17:53]

The CQ bit was checked by clemensh@chromium.org

[Clemens Hammacher, 2016-12-12 12:17:54]

The patchset sent to the CQ was uploaded after l-g-t-m from titzer@chromium.org,
yangguo@chromium.org
Link to the patchset: https://codereview.chromium.org/2563673002/#ps20001
(title: "Rebase")

[commit-bot: I haz the power, 2016-12-12 12:17:56]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-12 12:45:51]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1481545073496790,
"parent_rev": "c1aadf92b9a6916ca176053269ed7a4557660264", "commit_rev":
"465cba7c42bbb33de10f28c133e8b4c188fd802a"}

[commit-bot: I haz the power, 2016-12-12 12:45:54]

Description was changed from

==========
[wasm] Generate correct locations for error messages

The current logic in Isolate::GetLocationFromStackTrace just ignores
wasm frames, making the computed location point to the first javascript
frame, like this:

test.js:17: RuntimeError: divide by zero
module.exports.main();
               ^
RuntimeError: divide by zero
    at main (<WASM>[1]+5)
    at test.js:17:16

This CL not only fixes the location to point to the top-most wasm
frame, but also exposes to the embedder that the script of that location
is a wasm script, allowing for custom printing of wasm locations.
The Shell::ReportException method now checks for this flag, and prints
wasm locations like this:

<WASM>[0]+5: RuntimeError: divide by zero
RuntimeError: divide by zero
    at main (<WASM>[0]+5)
    at test/message/wasm-trap.js:15:16

R=titzer@chromium.org, yangguo@chromium.org
BUG=chromium:613110
==========

to

==========
[wasm] Generate correct locations for error messages

The current logic in Isolate::GetLocationFromStackTrace just ignores
wasm frames, making the computed location point to the first javascript
frame, like this:

test.js:17: RuntimeError: divide by zero
module.exports.main();
               ^
RuntimeError: divide by zero
    at main (<WASM>[1]+5)
    at test.js:17:16

This CL not only fixes the location to point to the top-most wasm
frame, but also exposes to the embedder that the script of that location
is a wasm script, allowing for custom printing of wasm locations.
The Shell::ReportException method now checks for this flag, and prints
wasm locations like this:

<WASM>[0]+5: RuntimeError: divide by zero
RuntimeError: divide by zero
    at main (<WASM>[0]+5)
    at test/message/wasm-trap.js:15:16

R=titzer@chromium.org, yangguo@chromium.org
BUG=chromium:613110

Review-Url: https://codereview.chromium.org/2563673002
==========

[commit-bot: I haz the power, 2016-12-12 12:45:55]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-12-12 12:46:10]

Description was changed from

==========
[wasm] Generate correct locations for error messages

The current logic in Isolate::GetLocationFromStackTrace just ignores
wasm frames, making the computed location point to the first javascript
frame, like this:

test.js:17: RuntimeError: divide by zero
module.exports.main();
               ^
RuntimeError: divide by zero
    at main (<WASM>[1]+5)
    at test.js:17:16

This CL not only fixes the location to point to the top-most wasm
frame, but also exposes to the embedder that the script of that location
is a wasm script, allowing for custom printing of wasm locations.
The Shell::ReportException method now checks for this flag, and prints
wasm locations like this:

<WASM>[0]+5: RuntimeError: divide by zero
RuntimeError: divide by zero
    at main (<WASM>[0]+5)
    at test/message/wasm-trap.js:15:16

R=titzer@chromium.org, yangguo@chromium.org
BUG=chromium:613110

Review-Url: https://codereview.chromium.org/2563673002
==========

to

==========
[wasm] Generate correct locations for error messages

The current logic in Isolate::GetLocationFromStackTrace just ignores
wasm frames, making the computed location point to the first javascript
frame, like this:

test.js:17: RuntimeError: divide by zero
module.exports.main();
               ^
RuntimeError: divide by zero
    at main (<WASM>[1]+5)
    at test.js:17:16

This CL not only fixes the location to point to the top-most wasm
frame, but also exposes to the embedder that the script of that location
is a wasm script, allowing for custom printing of wasm locations.
The Shell::ReportException method now checks for this flag, and prints
wasm locations like this:

<WASM>[0]+5: RuntimeError: divide by zero
RuntimeError: divide by zero
    at main (<WASM>[0]+5)
    at test/message/wasm-trap.js:15:16

R=titzer@chromium.org, yangguo@chromium.org
BUG=chromium:613110

Committed: https://crrev.com/222541dff51aba0623edc98bbecb6e1a35d22063
Cr-Commit-Position: refs/heads/master@{#41640}
==========

[commit-bot: I haz the power, 2016-12-12 12:46:10]

Patchset 2 (id:??) landed as
https://crrev.com/222541dff51aba0623edc98bbecb6e1a35d22063
Cr-Commit-Position: refs/heads/master@{#41640}