[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.

[Yang Guo]

Digging this thread up again since sometime last week it was mentioned that not everyone seems to have seen this: http://bit.ly/devtools-language-servers

Cheers,

Yang

On Fri, Oct 11, 2019 at 8:51 AM Benedikt Meurer <bme...@chromium.org> wrote:

--

[Benedikt Meurer]

Thanks for raising this again. A quick update on the current status here:

1. +Philip Pfaffe is working on a prototype of an (external) language component for WebAssembly right now, which consumes DWARF data and provides the DevTools front-end with break location and source mapping information. This current prototype is done by using LLDB embedded into a C++ server, which talks to the DevTools front-end via synchronous JSON-RPC. We want to do a bit more experimentation here, and once we know exactly what we need to do, start thinking about making the relevant parts of DevTools async and designing an API for language components.
   
2. +Eric Leese is working with the V8 Wasm teams at Google and Microsoft (+Bill Ticehurst's team) to make the necessary adjustments on the Wasm Runtime side to support stepping and source mapping correctly.
   

We currently don't have anyone working on prototyping a language component for TypeScript, and we're looking for help in this area. Maybe that's something that Microsoft folks would be interested to get into?

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/CAFSTc_jL8t1HswCPnOoJzo7E7MejRf-%2B%3DM%2B%2BrzJeWuESA%2BSQnw%40mail.gmail.com.

--

Benedikt Meurer

Chrome DevTools TL

bme...@google.com

[Benedikt Meurer]

Updating this thread as well, as not everyone is monitoring the WebAssembly/debugging#8 issue. Our current prototype solution looks roughly like this:

The Language Component part in DevTools front-end isn't separated as such, but rather tightly integrated with the Source Mapping at this point, but that's just the prototype.

The LLDB part currently lives in a separate server process, which has access to the file system and exposes a JSON-RPC API to the DevTools (Language Component). Initially we wanted to move all of this into a web worker inside DevTools, but given that we already know that we will likely need to deal with gigabytes of DWARF data, we are considering to let this live outside of the browser. There should be some way for the development HTTP server to signal where to find the Wasm Debug Server for a given .wasm module, for example in the form of an HTTP header, and DevTools just connects to that (a similar mechanism is used for the live reload functionality).

As far as LLVM/clang/Emscripten are concerned: So far we seem to be getting along quite well with DWARF for C/C++, and so we don't think we need anymore more complex. But instead we should focus on landing the necessary bits in the relevant projects ASAP.

Regarding the language component: The current line of thought here is to have the Language Component as a plugin for DevTools. In case of Wasm for C/C++, it will be just a thin wrapper around the JSON-RPC protocol talking to the dedicated server. For source mapped JavaScript, the Fallback Language Component will basically do the job that DevTools does today. And for future TypeScript integration, the TypeScript Language Component could be a plugin that comes with its own web worker, which runs tsc and does the mapping (or it could follow the Wasm C/C++ approach and have a dedicated server running).

cheers,

Benedikt