[PATCH] Have clang list the imported modules in the debug info

[David Blaikie]

On Mon, Feb 23, 2015 at 2:51 PM, Adrian Prantl <aprantl at apple.com> wrote:

>
> > On Jan 20, 2015, at 11:07 AM, David Blaikie <dblaikie at gmail.com> 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 <aprantl at apple.com>
> 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
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150223/5028031c/attachment.html>