For WebAssembly, I expect there will be two main kinds of debugging. One is debugging at the wasm level. The wasm binary format is defining symbol sections to provide basic information to assist this, and it'll be a generally low-level experience.
The other is high-level language debugging. It isn't feasible for browsers to support high-level language debuggers for all languages that will want to compile to wasm, so what we'll need are browser interfaces which allow web content to implement debugger functionality itself. Debug info supporting such a debugger would likely be plain DWARF, though it could be anything else a debugger might want, since the browser itself wouldn't be interpreting it. Dan On Wed, Mar 9, 2016 at 5:01 PM, Charles Vaughn <[email protected]> wrote: > > > On Wednesday, March 9, 2016 at 11:45:53 AM UTC-8, Alon Zakai wrote: >> >> For 1, I think the burden here should be on the browser debuggers. They >> have been making progress on improving responsiveness on large JS files. >> Helping them directly might make sense, for the open source ones, Chrome >> and Firefox. For Firefox, you can track progress here, >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1229092 >> <https://www.google.com/url?q=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1229092&sa=D&sntz=1&usg=AFQjCNHLDUrkwVPfWZsR-zVW75-YmF3qkg> >> >> > Awesome that this is being tracked. There's another aspect of this, and > that's it would be beneficial to debug highly optimized Javascript, pretty > much requiring separate metadata. > > >> For 2, there have been discussions of a "source maps 2" that would >> include more info, see >> >> https://github.com/source-map/source-map-rfc/issues >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fsource-map%2Fsource-map-rfc%2Fissues&sa=D&sntz=1&usg=AFQjCNFYjfVgjg2z7WhnUN5-txm2f631hw> >> > > Interesting, but doesn't seem like its gotten very far. I'm a bit > skeptical of a general object pretty printer approach that would work for > both heap stored objects and native-to-the-VM objects without either; a) > having to support running arbitrary code to restructure the objects or b) > having distinct code bases for each approach. > > >> >> >> There is also talk in WebAssembly about a debug format inspired by DWARF, >> so your idea may fall along similar lines, and if you're designing a new >> format for debugging, see >> >> >> https://github.com/WebAssembly/design/blob/c8137d9a6bdefd015f5daadd3f0eb233dc6996b6/FutureFeatures.md#source-maps-integration >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FWebAssembly%2Fdesign%2Fblob%2Fc8137d9a6bdefd015f5daadd3f0eb233dc6996b6%2FFutureFeatures.md%23source-maps-integration&sa=D&sntz=1&usg=AFQjCNEdUl3gVgDOBXFDZaX8omN_wucilQ> >> >> (WebAssembly is the future in this space, so it might make sense to focus >> on that - although, that future will take a while longer to get here.) >> >> > So digging around that link and the repository, I didn't find any specific > mentions to DWARF. That being said, as the WebAssembly backend is a proper > AsmPrinter, it's much easier to emit DWARF, as much of that support is > already built in to LLVM. I'm looking forward to being able to target WASM > for this type of stuff, but with it's early stages, and the need to support > non WASM browsers still in my future, there's still value for me in getting > some level of debugging support working. > > >> Overall, I'd be a little worried about us inventing a new debug format >> here - it should be, as much as possible, a shared project with the entire >> ecosystem. >> > > For ecosystem, are you thinking asm.js + WebAssembly? In the case of WASM, > this should probably just work. The type graph is 75% of the complexity > here, and would be reusable with any system that uses a flat heap and > structures its composite types in a relatively straightforward way. The > next 20% of the complexity is the intrinsics for associating values in the > compiled program with variables in the source code. > > Those are currently realized in my prototype like this: > > $someVar = c[10289>>2]; > metadata_llvm_dbg_value_local($someVar, 123, 0, "someVar"); > > A debugger can hook that function, and update a local variable view. As > long as WASM has some ability to call external functions, that's relatively > easy to add. > > I feel like a minimal system delivered in the interim could provide > benefits without being blocked on WASM, as well as represent a smooth > upgrade path going forward. There's also a class of work around this topic > that would be largely agnostic to the format, such as debugger UIs and > complex type visualizers. Landing something asm.js early would let that > ecosystem have time to develop, giving WebAssembly a head start. > > > > >> >> 3 is, I believe, an emscripten bug. It would be great to have that fixed! >> > > I may separate the work I have for that, as it's standalone from the > object printer stuff. > > Thanks for your feedback. > > >> >> On Mon, Mar 7, 2016 at 6:23 PM, Charles Vaughn <[email protected]> wrote: >> >>> As part of my company's (Tableau Software) work with Emscripten, we've >>> wanted to come up with better tooling around debugging. 3 main pain points >>> we're hoping to address: >>> >>> 1. Debugging large code bases results in large (50+MB) size output >>> Javascript, which prevents any sort of interactive debugging, at least on >>> the tools I've used >>> 2. Heap allocated data is pretty opaque >>> 3. Source maps are currently busted on any level of optimization >>> >>> I have a work in progress design doc here: >>> https://gist.github.com/hackcasual/ea77cc31c6dafdda7274 >>> Changes to JSBackend to output the file format and add in the debug >>> intrinsics are here: >>> https://github.com/kripken/emscripten-fastcomp/compare/incoming...hackcasual:tableau-debugger-work >>> >>> I've got an initial driver (though out of sync with the format generated >>> in the current changes to JSBackend), you can see here to have some >>> understanding of how the types are interpreted: >>> https://gist.github.com/hackcasual/efb93d70c4c3e87cd1ee >>> >>> More work needs to be done to get this into shipping shape, but I'd like >>> to kick of discussions now. >>> >>> Thanks! >>> >>> Charles Vaughn >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
