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

[David Blaikie]

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).

[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/20150120/9a461736/attachment.html>