On Tuesday, March 8, 2016 at 1:29:11 AM UTC-8, Floh wrote: > > Exciting :) > > What would the debugging frontend look like? I guess this would not be > fully compatible with existing source map debuggers (e.g. in browser > devtools)? >
In the case of Chrome's devtools, you can take the existing source: https://github.com/ChromeDevTools/devtools-frontend and use it to debug an existing Chrome browser with remote debugging enabled. I don't have experience with Firefox's devtools, but a quick glance seems to indicate it may even be able to be extended without making core changes. My current plan is to have a backend javascript API that the devtools can use, or is even callable from the regular Javascript console. > > I've been thinking it might be better to hack/extend one of the existing > Chromium/Electron based editors (like Atom, or VS Code) to support > emscripten-specific debugging extensions. VS Code seems to have an existing > plugin infrastructure for debuggers: > https://code.visualstudio.com/docs/extensions/example-debuggers > > That's really slick, the v8chromium debug protocol is what the chromium dev tools use under the hood, so should be straightforward to share work. Also, it probably makes sense to align this effort with the WebAssembly > project? So that your solution wouldn't become completely obsolete once the > transition to WebAssembly starts. > > I agree. I'm not too familiar with the current state of the wasm backend, but I've generally tried to design things in such a way to not overly depend on how the asm.js backend does things. In particular, except for vtable_offsets all of the debug fields can be generated directly from LLVM bitcode. > Cheers, > -Floh. > > Am Dienstag, 8. März 2016 03:23:27 UTC+1 schrieb Charles Vaughn: >> >> 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.
