1380677 - Make Wasm debugger follow "all operations have a visible effect" paradigm with an Autos window?

Status: NEW

(DevTools :: Debugger, enhancement, P5)

Description

[Jukka Jylänki]

Now when stepping through statements in the linear format of wasm code, the activity is a bit hidden from sight. Before a statement executes, it is not possible in some cases to observe the values of the inputs, and once the statement has executed, the effect of that statement is not shown.

See the attached screenshot for an example. There the debugger is paused to next execute an instruction

get_global $global12

When observing this instruction:
 - Mouse hovering on $global12 does not yet work (bug 1380647).
 - conceptually there is no mapping (yet) to which variable this is in question (here $global12 is in fact STACKTOP (bug 1380642)
 - On the top right hand side, there is a box "Watch Expressions". Typing in $global12 in that box does not show the value of $global12
 - On the bottom right hand side, there is the box Scopes with Block/Window variables, though $global12 is not shown there either.
 - At the very bottom, there is the JS context interpreter, but typing in $global12 does not have a meaning there.

When one steps over the statement, there is also no visible presented effect of what happens on the execution of get_global $global12, in this case since we do not visualize the operand stack (bug 1380651).

Borrowing from Visual Studio's x86 asm debugger window ( http://www.kipirvine.com/asm/debug/vstudio2010/S5.gif ), they have a well implemented design where before each operation, the inputs to the operation can be readily observed:
 - mouse hovering on top of registers (EAX,...) or variables shows the value of that variable before the call
 - there is a watch window where one can type in a register or a variable name, and its value is shown in the window. When the value changes, the value is highlighted in red for the next instruction.
 - when a value of a variable changes, it is immediately populated in an "Autos" window, along with its input operands that participated in the instruction. The Autos window is identical in interaction to the Watch window, but it always shows variables that change their values. Once the size of the Autos window becomes too large from these autopopulated variables, the LRU autopopulated variables begin to disappear to give way.

In particular the last item gives a good impression of seeing a "physical state machine" on the screen as it is operating the code, because the Autos window is automatically throwing the inputs and outputs of the operations at the user's face as the instructions are executed. This makes the effect of statements show up explicitly to the user, and in particular, it is a good aid for self-teaching the user about what the instructions do.

Could we also create this kind of Autos window, that is a Watch window that autopopulates the inputs and outputs to Wasm instructions? Along with being able to pin variables to Watch windows and mouse-hovering to read, that would give a good impression of observing a physical state machine.

Comment 1

[Jukka Jylänki]

Attachment: Screen Shot 2017-07-13 at 5.42.19 PM.png

Comment 2

[Yury Delendik (:yury)]

After bug 1387115, globals and memory is now accessible via scope variable. It is also possible to add watches in form of JS expression.

Comment 3

[Luke Wagner [:luke]]

So based on comment 2, it seems like the remaining feature request in this bug is an "Autos" window similar to what MSVC has.  Is that right Jukka?

Comment 4

[Jukka Jylänki]

Let me NI myself, I'll give a look at how this works after bug 1387115. Great progress on this Yury!