WASM debugging support #1789
Assignees
Labels
feature-request
Request for new features or functionality
on-testplan
VS Code - Issue added to test plan
Milestone
Comments
This was referenced Aug 25, 2023
Closed
connor4312
added a commit
that referenced
this issue
Aug 25, 2023
Supports viewing, stepping through, and setting breakpoints in webassembly (decompiled as WAT) in the editor. Includes a basic tmLanguage for WAT.  Unfortunately we eagerly have to decompile WASM in order to get line mappings to show e.g. in breakpoints. Location mapping is currently mostly synchronous and I didn't want to make everything async for webassembly. However, we don't keep the WAT source in memory, instead request it again if it's needed. I opted to do this to reduce memory usage for user applications that just happen to contain WASM where they aren't always interested in debugging it. For #1789 Fixes #1715 on the way
connor4312
added a commit
that referenced
this issue
Aug 27, 2023
* feat: support basic webassembly debugging Supports viewing, stepping through, and setting breakpoints in webassembly (decompiled as WAT) in the editor. Includes a basic tmLanguage for WAT.  Unfortunately we eagerly have to decompile WASM in order to get line mappings to show e.g. in breakpoints. Location mapping is currently mostly synchronous and I didn't want to make everything async for webassembly. However, we don't keep the WAT source in memory, instead request it again if it's needed. I opted to do this to reduce memory usage for user applications that just happen to contain WASM where they aren't always interested in debugging it. For #1789 Fixes #1715 on the way * retain wasm-set breakpoints between reloads
65 tasks
2 tasks
62 tasks
connor4312
added a commit
that referenced
this issue
Sep 15, 2023
Enables stepping around and setting breakpoints in native code. Variables represenation is still a todo, and this needs some polish. It refactors the `Source.sourceMap` into a more generic location provider, which may be backed by the new IWasmSymbols interface. This then talks to the DWARF debugger. The SourceContainer's `_sourceMaps` are also now just folded into the `Source.sourceMap`; that information was duplicate and the only benefit was deduplication if two sources had the same sourcemap, but this is really rare. This also made all location mapping asynchronous, so there were a few refactors around there, too. It also refactors how I implemented WAT (text format decompilation) last iteration. That previously "pretended" the source of the WASM was WAT, but this caused issues because the location transformation we did on the scripts is done before location mapping. So instead, the WAT is an extra fake 'file' in the symbols and we resolve any unknown locations into the WAT file. One that that _doesn't_ work yet is entrypoint breakpoints for wasm, which means that breakpoints set before the debug session starts may be missed. I have a thread out to the Chromium folks to see if there's a solution to this. For #1789
connor4312
added a commit
that referenced
this issue
Sep 15, 2023
Enables stepping around and setting breakpoints in native code. Variables represenation is still a todo, and this needs some polish. It refactors the `Source.sourceMap` into a more generic location provider, which may be backed by the new IWasmSymbols interface. This then talks to the DWARF debugger. The SourceContainer's `_sourceMaps` are also now just folded into the `Source.sourceMap`; that information was duplicate and the only benefit was deduplication if two sources had the same sourcemap, but this is really rare. This also made all location mapping asynchronous, so there were a few refactors around there, too. It also refactors how I implemented WAT (text format decompilation) last iteration. That previously "pretended" the source of the WASM was WAT, but this caused issues because the location transformation we did on the scripts is done before location mapping. So instead, the WAT is an extra fake 'file' in the symbols and we resolve any unknown locations into the WAT file. One that that _doesn't_ work yet is entrypoint breakpoints for wasm, which means that breakpoints set before the debug session starts may be missed. I have a thread out to the Chromium folks to see if there's a solution to this. For #1789
connor4312
added a commit
that referenced
this issue
Sep 20, 2023
connor4312
added a commit
that referenced
this issue
Sep 20, 2023
connor4312
added a commit
that referenced
this issue
Sep 20, 2023
|
Does this currently support the "path substitution" feature from the Chrome plugin? I compile in a container, which means that the source file paths are incorrect for the machine I want to debug on. Appreciate all the work that's been done on this and I'm eager to try it out! |
|
The path goes through the usual path mapping logic in js-debug, so for your case you'd want to set the localRoot/remoteRoot in your launch.json as described in https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_remote-debugging |
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
js-debug should be able to debug WebAssembly.
There's two parts of this. The base devtools experience allows users to step into and around WebAssembly, displayed as WAT. Supporting this can be done pretty easily.
The next step is giving source-level support for debugging. The Chromium team recently made their DWARF debugger open source. While this very sadly doesn't work out of the box for Rust yet, it should eventually (we can hope), and it does support any other language that outputs DWARF symbols.
While the extension is built for integration in Chrome devtools, it looks like it's architected in a way that pretty much all the work happens in the
DevToolsPluginWorker. I think that we could package this up into an node module that the extension could consume and run in a Node worker_thread.The downside is the the DWARF SymbolBackend includes(?) chunks from LLVM and even compressed is pretty hefty at 11MB, so we may not want to have it included in vscode by default like js-debug is. My thought is that we can have an extension that exports a known API for js-debug to consume, alongside an npm package that ships only the types in the package (or maybe I just copy the types directly into js-debug). We can try to both
require('vscode').extensions.getExtension('ms-vscode.js-debug-dwarf')as well asrequire('@vscode/dwarf-debugging')to enable pure DAP consumers to get this too. And of course we can prompt the user to install this extension when they first step into WASM code.The text was updated successfully, but these errors were encountered: