[RFC] DevTools Language Servers Proposal

[Benedikt Meurer]

Hey folks,

Following up on the prototyping work around Wasm Debugging with LLDB, we're starting to realize that it might not work out to just pull in LLDB combined with DWARF to create an excellent Wasm debugging experience. What we are looking for in the end is a solution, where DevTools is able to debug applications consisting of various JavaScript and WebAssembly parts seamlessly. Based on the current experiments (thanks a lot to the folks that ran the experiments here, which helped a lot to gain a better understanding of the problem space) it seems that full LLDB is always going to assume that it's driving the car, when in reality the JavaScript engines debugger has to drive the car in order to make the whole thing work across language barriers.

Following along this thought we realized that for modern JavaScript we already have very similar problems to WebAssembly. I.e. the code that the application is written in is usually not the code that the browser engines sees. And the current solution here - which is source maps - is far from sufficient to address this issue.

This brought us to consider the idea of language servers, which has been proposed before, as a way to make forward progress here. Some discussions have already happened around this, but I'd like to make sure to include everyone here from the beginning, so I created an initial design proposal (http://bit.ly/devtools-language-servers), so let's use that as a basis for further discussion. In essence it describes two possible high level solutions how to address the current problem.

Please let me know what you think.

cheers,

Benedikt

--

Benedikt Meurer

Chromium DevTools TL

bme...@chromium.org

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[bme...@google.com]

Per popular demand, we renamed this to "DevTools Language Components" to avoid the confusion with Language Servers for IDEs.

cheers,

Benedikt

[Philip Pfaffe]

Hi everyone,

just to be sure I fully understand the plan. We intend to wrap LLDB (or more specifically, the wasm debug module, which then wraps LLDB) inside a language component which connects with the devtools frontend through CDP? Or are we looking to replace LLDB with our own debugger interpretation?

Best regards,

Philip

--
You received this message because you are subscribed to the Google Groups "devtools-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devtools-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/devtools-dev/CAGowDna6zOniX3Svj3z8AJHzPo%3DOgumGkOPLBNdieqjsPTWrHQ%40mail.gmail.com.

[Benedikt Meurer]

The core realization is that relying on "just using LLDB" is not going to give us the kind of seamless debugging experience that we hope to get for the web (in Chromium DevTools), since LLDB insists to sit on the driver seat. Instead we are thinking of a solution here were we use the single debugger built into the JS/Wasm (i.e. the V8 debugger), and have that manage all the breakpoints, control the stepping, and also manage the call stacks. The language components (which might use parts of LLDB if necessary) will only be responsible to help the debugger translate locations and expressions between source and target language. So, yes, we're essentially looking to replace LLDB with our own debugger.

Note: This is solely thinking about the Chromium DevTools Frontend use case for now. For standalone Wasm purposes, LLDB looks like a very good (and probably the best) solution.

cheers,

Benedikt

You received this message because you are subscribed to a topic in the Google Groups "devtools-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/devtools-dev/X0bwUUmCajo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to devtools-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/devtools-dev/CANncsuorOHi0kqhZBrw1Q2FFpNebJmqPYkFYr-trn1sGkzNCVw%40mail.gmail.com.

[Yang Guo]

To expand on this: for the WebAssembly on the web use case, we expect JavaScript to interact with one more multiple Wasm modules. If each Wasm module comes with its LLDB for debugging, LLDB needs to play along with other debuggers. Iiuc this is not easily feasible, and we should have a single debugger exert control over debugging capabilities of every Wasm module to offer a seamless debugging experience.

Yang

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/devtools-dev/CAGowDnZDSSi07vHRcA%2B1WLix_c0m66_YNJTiQWNYjZgedbPdDw%40mail.gmail.com.