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 <cva...@gmail.com > <javascript:>> 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 <cva...@gmail.com> 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 emscripten-discuss+unsubscr...@googlegroups.com. >>>> 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 emscripten-discuss+unsubscr...@googlegroups.com <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 emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
