Wasm Language Components for browser DevTools

[bmeurer]

On the Chromium DevTools side we've recently started a discussion around a concept we call Language Components, which would allow developers to supply plugins to debug (parts of) their web applications in terms of the source language. You can think of these language components as an extension to source maps. Similar ideas have been proposed for DevTools in the past.

One primary driver here is obviously Wasm, but we also believe that language components will help us close the gap for modern web development in general, since the JavaScript that is shipped to the browser only occasionally matches the code that was written by the developers, and source maps aren't powerful enough to cover all the interesting aspects.

In a way these language components are a more general form of the debugging modules that we had in mind initially, but with some potentially interesting differences. In particular it would be nice (for security, test-ability and extensibility) to have a decouple the language component from the underlying engine and instead provide an (asynchronous) query interface which is used by the browser to perform the necessary operations mapping between target language (JS & Wasm) and source language.

We're still in the very early stages and doing some prototyping to see what's possible and how, but please share any feedback that you have on the idea / design and join the discussion.

[bmeurer]

@fitzgen @tschneidereit @linclark Any comments here from the Mozilla side? @pfaffe has been working on a prototype for Chromium DevTools, and it looks like for C/C++ the Language Component based on DWARF data and parts of LLDB is sufficient.

[bmeurer]

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.

cc @hashseed @yurydelendik

[kripken]

As you mentioned Emscripten, an update from there: I am still investigating how to update DWARF info through Binaryen optimizations (without which, Emscripten compiled code can't have valid DWARF). One main option is using @yurydelendik's wtmap-utils, another is to integrate DWARF parsing in Binaryen itself.

[RReverser]

DWARF parsing in Binaryen itself

I remember you mentioned using libdwarf as an option on one of the threads - is this what you mean by DWARF parsing in Binaryen?

[kripken]

@RReverser

libdwarf is one of the top options, yes. The other is LLVM.