[PATCH] Add a DIModule debug info metadata node to the IR.

[Adrian Prantl]

Pinging dblaikie.

Context: 
This patch adds an IR node for the dwarf tag DW_TAG_module. A rather lengthy thread on this can be found on cfe-commits (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150316/125724.html).

The primary use-case for DW_TAG_module is to record modules @imported by the current compile unit, so a clang-based debugger (like LLDB) can import the same modules to replicate the environment of the current CU before dropping into the expression evaluator. This way the debugger can import types directly from the module and has access to types that are not representable in DWARF (uninstantiated templates). The debugger needs an accurate list of the (sub-)modules imported by any CU, since any two (sub-)modules may conflict.

A concern was that using DW_TAG_imported_module for this might confuse debuggers since C++ namespaces are represented similarly. That said, DW_TAG_imported_module (DW_TAG_module) is exactly how the DWARF standard recommends representing modules. I also brought this up on the dwarf-discuss mailing list, and the general consensus was to follow the standard.

[Included here for completeness, since its been discussed at length on cfe-commits, a //potential// secondary use-case for this is for module debugging debug info:
For non-ODR languages like C and Objective-C the mangled type names produced by the clang indexer are only unique within a module. LLVM computes type signatures by hashing the mangled type name, which doesn't work in this case. **One** way of disambiguating the resulting type signatures is to put forward declarations of the types and their declcontext inside the DW_TAG_module they are defined in and perform a complete DWARF-style hash of the type+context.
Since there are also other ways of solving this problem, such as introducing a stable clang module hash and hashing it together with the mangled name, I'd like to postpone this discussion and revisit it when it comes up.]


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D9614

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/