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] > <javascript:>> 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] <javascript:>. >> 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.
