[inspector] [wasm] Implement GetPossibleBreakpoints

[inspector] [wasm] Implement GetPossibleBreakpoints

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 V8DebuggerScript does the translation from fake script id to v8
script ids in both directions.

I extended the test case to include the respective source line, such
that you can easily check that the reported locations are correct. It
now also queries ranges within the script to test that this also works.

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

[Clemens Hammacher, 2016-11-28 16:17:45]

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

[commit-bot: I haz the power, 2016-11-28 16:17:57]

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-11-28 16:21:04]

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

[commit-bot: I haz the power, 2016-11-28 16:21:05]

Dry run: Try jobs failed on following builders:
  v8_win64_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng/builds/18523)
  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_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel_ng/builds/18639)

[Clemens Hammacher, 2016-11-28 16:22:31]

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

[commit-bot: I haz the power, 2016-11-28 16:22:35]

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-11-28 16:53:09]

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

[commit-bot: I haz the power, 2016-11-28 16:53:10]

Dry run: This issue passed the CQ dry run.

[Clemens Hammacher, 2016-11-29 09:15:28]

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

[commit-bot: I haz the power, 2016-11-29 09:15:37]

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-11-29 09:52:35]

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

[commit-bot: I haz the power, 2016-11-29 09:52:36]

Dry run: This issue passed the CQ dry run.

[kozy, 2016-11-30 17:36:29]

kozyatinskiy@chromium.org changed reviewers:
+ kozyatinskiy@chromium.org

[kozy, 2016-11-30 17:36:29]

We use get possible breakpoints to get locations and then set breakpoint in this
location.
Is it possible to set breakpoints in wasm script? Does provisional breakpoint
work?
Protocol has following contract: if position was returned as possible breakpoint
position then user can set breakpoint by this position and will pause in this
position when execute code where breakpoint was set.

[kozy, 2016-11-30 17:38:16]

https://codereview.chromium.org/2536763002/diff/40001/test/inspector/debugger...
File test/inspector/debugger/wasm-get-breakable-locations.js (right):

https://codereview.chromium.org/2536763002/diff/40001/test/inspector/debugger...
test/inspector/debugger/wasm-get-breakable-locations.js:107: function
checkGetBreakableLocations(wasmScriptNr) {
You can improve this test by adding two steps after getPossibleBreakpoints:
setBreakpoint by each possible location and then run wasm module and check that
execution actually was paused in reported locations.

[Clemens Hammacher, 2016-11-30 17:52:19]

https://codereview.chromium.org/2536763002/diff/40001/test/inspector/debugger...
File test/inspector/debugger/wasm-get-breakable-locations.js (right):

https://codereview.chromium.org/2536763002/diff/40001/test/inspector/debugger...
test/inspector/debugger/wasm-get-breakable-locations.js:107: function
checkGetBreakableLocations(wasmScriptNr) {
On 2016/11/30 at 17:38:16, kozyatinskiy wrote:
> You can improve this test by adding two steps after getPossibleBreakpoints:
setBreakpoint by each possible location and then run wasm module and check that
execution actually was paused in reported locations.

Breakpoint support is not there yet, but is a P1 for Chrome 57 (where we will
launch WebAssembly). It is the main thing I will work on in the next weeks. I
want to finish it before Christmas.
Once we have breakpoint support, I will extend the test cases.

If you are uncomfortable with landing this as is, I can also wait with landing
until breakpoint support is there.
I just need to know that you are OK with the current implementation, such that I
can move on.

[kozy, 2016-11-30 18:37:10]

On 2016/11/30 17:52:19, Clemens Hammacher wrote:
> If you are uncomfortable with landing this as is, I can also wait with landing
> until breakpoint support is there.
> I just need to know that you are OK with the current implementation, such that
I
> can move on.

Our frontend and possible protocol clients are uncomfortable with landing this
:)
I think as soon as we'll take a look on CL that send all scriptParsed events on
wasm module compiled event and move location translation logic into WasmScript -
we can land all these CLs.

[Clemens Hammacher, 2016-12-02 17:23:32]

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

[commit-bot: I haz the power, 2016-12-02 17:23:37]

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-02 17:50:43]

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

[commit-bot: I haz the power, 2016-12-02 17:50:44]

Dry run: This issue passed the CQ dry run.

[Clemens Hammacher, 2016-12-19 15:32:46]

On 2016/11/30 at 18:37:10, kozyatinskiy wrote:
> On 2016/11/30 17:52:19, Clemens Hammacher wrote:
> > If you are uncomfortable with landing this as is, I can also wait with
landing
> > until breakpoint support is there.
> > I just need to know that you are OK with the current implementation, such
that I
> > can move on.
> 
> Our frontend and possible protocol clients are uncomfortable with landing this
:)
> I think as soon as we'll take a look on CL that send all scriptParsed events
on wasm module compiled event and move location translation logic into
WasmScript - we can land all these CLs.

I will first land this change without exposing it via inspector
(http://crrev.com/2588763002), then incrementally add breakpoint support, and in
the end connect everything to the inspector interface.

[titzer, 2016-12-19 16:41:29]

On 2016/12/19 15:32:46, Clemens Hammacher wrote:
> On 2016/11/30 at 18:37:10, kozyatinskiy wrote:
> > On 2016/11/30 17:52:19, Clemens Hammacher wrote:
> > > If you are uncomfortable with landing this as is, I can also wait with
> landing
> > > until breakpoint support is there.
> > > I just need to know that you are OK with the current implementation, such
> that I
> > > can move on.
> > 
> > Our frontend and possible protocol clients are uncomfortable with landing
this
> :)
> > I think as soon as we'll take a look on CL that send all scriptParsed events
> on wasm module compiled event and move location translation logic into
> WasmScript - we can land all these CLs.
> 
> I will first land this change without exposing it via inspector
> (http://crrev.com/2588763002), then incrementally add breakpoint support, and
in
> the end connect everything to the inspector interface.

lgtm

[Clemens Hammacher, 2017-01-24 20:38:06]

Closing this old CL, new one is here: http://crrev.com/2655653003
General breakpoint and stepping support already landed in V8, so it's much
shorter now.