On Mon, Feb 23, 2015 at 2:51 PM, Adrian Prantl <[email protected]> wrote:
> > > On Jan 20, 2015, at 11:07 AM, David Blaikie <[email protected]> wrote: > > > > My vague recollection from the previous design discussions was that > these module references would be their own 'unit' COMDAT'd so that we don't > end up with the duplication of every module reference in every unit linked > together when linking debug info? > > > > I think in my brain I'd been picturing this module reference as being an > extended fission reference (fission skeleton CU + extra fields for users > who want to load the Clang AST module directly and skip the split CU). > > Apologies for letting this rest for so long. > > Your memory was of course correct and I didn’t follow up on this because I > had convinced myself that the fission reference would be completely > sufficient. Now that I’ve been thinking some more about it, I don’t think > that it is sufficient in the LTO case. > > Here is the example from the > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040076.html: > > foo.o: > .debug_info.dwo > DW_TAG_compile_unit > // For DWARF consumers > DW_AT_dwo_name ("/path/to/module-cache/MyModule.pcm") > DW_AT_dwo_id ([unique AST signature]) > > .debug_info > DW_TAG_compile_unit > DW_TAG_variable > DW_AT_name "x" > DW_AT_type (DW_FORM_ref_sig8) ([hash for MyStruct]) > > In this example it is clear that foo.o imported MyModule because its DWO > skeleton is there in the same object file. But if we deal with the result > of an LTO compilation we will end up with many compile units in the same > .debug_info section, plus a bunch of skeleton compile units for _all_ > imported modules in the entire project. We thus loose the ability to > determine which of the compile units imported which module. > Why would we need to know which CU imported which modules? (I can imagine some possible reasons, but wondering what you have in mind) > I think it really is necessary to put the info about the module imported > into the compile unit that imported it. Or is there a way to do this using > the fission capabilities that I’m not aware of? > > -- adrian > > > > > [rambling a bit more along those lines: > > This would work fine in the case of the module (now an object file) > containing all the static debug info > > The future step, when we put IR/object code in a module to be linked > into the final binary, we could put the skeleton CU in that object file > that's being linked in (then we wouldn't need to COMDAT it) or, optionally, > link in the debug info itself (skipping the indirection through the > external file) if a standalone debug info executable was desired] > > > > > > > On Tue, Jan 20, 2015 at 9:39 AM, Adrian Prantl <[email protected]> > wrote: > > As a complementary part of the module debugging story, here is a > proposal to list the imported modules in the debug info. This patch is not > about efficiency, but rather enables a cool debugging feature: > > > > Record the clang modules imported by the current compile unit in the > debug info. This allows a module-aware debugger (such as LLDB) to @import > all modules visible in the current context before evaluating an expression, > thus making available all declarations in the current context (that > originate from a module) and not just the ones that were actually used by > the program. > > > > This implementation uses existing DWARF mechanisms as much as possible > by emitting a DW_TAG_imported_module that references a DW_TAG_module, which > contains the information necessary for the debugger to rebuild the module. > This is similar to how C++ using declarations are encoded in DWARF, with > the difference that we're importing a module instead of a namespace. > > The information stored for a module includes the umbrella directory, any > config macros passed in via the command line that affect the module, and > the filename of the raw .pcm file. Why include all these parameters when we > have the .pcm file? Apart from module chache volatility, there is no > guarantee that the debugger was linked against the same version of clang > that generated the .pcm, so it may need to regenerate the module while > importing it. > > > > Let me know what you think! > > -- adrian > > > > > > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
