Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First version of DebuggingFramework.md. #708

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

dekimir
Copy link
Member

@dekimir dekimir commented Jun 15, 2016

@lukewagner
Copy link
Member

Thanks for writing this up! At a high-level, this matches my basic understanding of the idea.


For reference, the entities are charted in the figure below:

![Entities making up the debug framework](wasm-debug-chart.png)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice chart! I'd put the "Debugger" box inside the browser box since it's executing JS or wasm code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I felt that the wasm module and the debugger should be shown outside, because they don't come with the browser but are downloaded. Then I try to explain in the text how they are used by the browser when obtained.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC 4. and 5. are what you're specifying here, right? It sounds like @lukewagner wants to drop 3. from the diagram, but you'd rather keep it because it can be separate (not being specified in this doc)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, this aims to specify 3 and 5, while leaving 4 unspecified (other than saying how the debugger can find the debug info and source files). The way the debugger interprets the debug info will be hidden from other actors in this picture, freeing the debugger implementers to choose whatever suits them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point and just noticed that "wasm module" is also, symmetrically, outside the box.

@sunfishcode
Copy link
Member

Overall this looks like a good start.

This specifies the browser devtools as the UI that the user will be interacting with. Another idea which has been discussed is that debuggers could provide their own UI, perhaps in a frame. The proposal here has the advantage that it should be easier to develop simple debuggers, because debugger writers need not implement their own UI, as the browser devools UI will often be sufficient. However, some debuggers may still want their own UI, for example to provide greater source-language-specific customization. Would it be difficult to accommodate this option in this proposal?

@dekimir
Copy link
Member Author

dekimir commented Jun 15, 2016

@sunfishcode: agree that some debuggers will want to provide their own UI (eg, Brackets and IntelliJ, which already do so for JS). That requires exposing the debugger<>debuggee interface as a remote-client protocol. We'd probably want to standardize the protocol so the external debugger only need implement it once (and not once per supported browser). I guess the question is how hard is it to standardize the remote-debugging protocols of multiple browsers?

#WebAssembly Debugging

This is a design proposal for enabling source-level debugging of WebAssembly
modules.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a bit redundant, given that we're in the design repo ;-)

Add missing operations the flows require.

Specify the debugger operations more precisely.
@AndrewScheidecker
Copy link

I'd love for there to be a low-level debugging API that is implemented by the WASM VM:

  • A query to enumerate threads
  • A query to get the current call stack from a thread: an array of frames, each frame containing the function (maybe as a module instance pointer + function index), bytecode offset, local variable and operand stack values (if known)
  • Queries to get the value of non-exported module instance definitions: memories, tables, global and in the future thread-local variables
  • Commands to pause/resume execution of a thread
  • Commands to add/remove breakpoints: when execution reaches some bytecode address in a function, suspend the thread and enqueue a message to the debugger
  • A command to register a message queue to receive notifications of breakpoints, traps, etc

The goal would be to factor source-level debugging out of the WASM VM, to allow it to be implemented in unprivileged code, and to allow the source-level debugging implementations to be portable between different WASM VM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants