Yes, the current roadmaps have the 2nd type happening after the MVP. Dan
On Wed, Mar 9, 2016 at 5:50 PM, Charles Vaughn <[email protected]> wrote: > I assume the 2nd type would be some time after the MVP? > > On Wednesday, March 9, 2016 at 5:29:12 PM UTC-8, Dan Gohman wrote: >> >> 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. > -- 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.
