Enable choice of debugger extension for WebAssembly modules with DWARF debug info.

[mikaelwaltersson]

Is your feature request related to a problem? Please describe.

The javascript debugger is hardcoded to use the ms-vscode.wasm-dwarf-debugging extension for supporting WebAssembly modules with DWARF debug info. That extension is mostly a thin layer around the https://github.com/ChromeDevTools/devtools-frontend.git code maintained by Google, this makes it really cumbersome / hard to contribute new features and bug fixes for the extension.

The current options available if one wants to fix a bug or add features to the extension:

• Compile a new / forked version of the extension (still named ms-vscode.wasm-dwarf-debugging) and distribute the VSIX file outside of the VSCode extensions marketplace (see https://github.com/mikaelwaltersson/vscode-dwarf-debugging/releases/tag/release-2025-08-21).

• Fork this repository to change the reference to ms-vscode.wasm-dwarf-debugging, possibly combining it to a single extension and publishing it to the VSCode extension marketplace. This is obviously not ideal as the JavaScript debugger is shipped with VSCode and you would be replacing the whole JavaScript debugging experience just to support for DWARF enabled WebAssembly modules.

Describe the feature you'd like

A way for the VSCode user to be able to select another "WebAssembly DWARF Debugging" compatible extension instead of ms-vscode.wasm-dwarf-debugging.

A simple solution would be to just add a setting where the user can specify the identifier for another extension to be used instead, for example "debug.javascript.wasm-dwarf-debugging-ext": "mwaltersson.wasm-dwarf-debugging" (just an example, not an actual published extension.)

This would make it possible to add support for Rust types which is missing in the Chromium devtools c++ extension.

[connor4312]

I don't plan to do this -- the 'API' between the JS debugger and the wasm-dwarf-debugging extension is not a stable API and may change between revisions of the extension. The only reason they're separate is because the wasm-dwarf-debugging stuff is fairly large and we did not want to take the bundle size in the base extension for something that a minority of users would ever use. However if you have contributions you would like to make to the the wasm-dwarf-debugging extension I would be happy to review them.

[mikaelwaltersson]

That is understandable, formalizing a proper API for the communication between the two extensions would mean additional work and not really desirable either as the separation mostly comes down to the size of SymbolsBackend.wasm as you point out. I'll go ahead and close this issue.

I've created a PR (microsoft/vscode-dwarf-debugging#8) with the following contributions:

• Fixed the bug where invalid URL parsing code "crashes" the extension for certain file paths in the DWARF debug info (https://issues.chromium.org/issues/401522579)
• Updated the formatting of C/C++ string values so they are quoted and escaped, that way they are properly shown as string values in the VSCode debug views.
• Added support for Rust types, discriminated unions and basic core library types.

There are some other minor fixes etc as well all described in the description of the PR.

All this required a copy of relevant parts of the original Devtools C++ extension source code in order to make changes to them which makes this PR quite big at 100+ files. I tried to make the review work easier by organizing the commit history so that the reviewer can distinguish what is just a verbatim copy of the original source code and what is changes / new code.

[connor4312]

Thank you! I apologize that I didn't see that PR earlier. Happy to work on getting it merged in!