There is currently a discussion on the clang mailing list regarding the DWARF representation for modules, and I was wondering what the recommended best practices for situations like this are.
Clang supports Modules (http://clang.llvm.org/docs/Modules.html) for C, Objective-C, and C++, which are aimed at being a more sane alternative to header files. Although clang has supported modules for several years now, this is still a language extension that has yet to be standardized. There are several ways how modules can be used to improve the debugging experience. For example, if we record the imported modules in the debug info, the debugger can import these modules before evaluating an expression and thus make available symbols that were not even used (but imported) by the program being debugged. To record the imported modules DWARF actually provides a well-defined way, which is DW_TAG_imported_module (section 3.2.4), which sounds like an obvious way to encode this — if it didn’t also have a very specific meaning for C++, where it is (ab)used to encode “using” directives. My first intuition would be to still use DW_TAG_imported_module according to the DWARF standard (DWARF is supposed to describe concepts, not specific language features); but there is a risk of confusing existing debuggers that expect exactly an imported C++ namespace inside a DW_TAG_imported_module. The safe solution would be to emit a vendor-specific DW_TAG_LLVM_imported_module for now and then later (e.g., when modules are an official part of C++1z?) bring this up before the committee. Whats the recommended best practice? -- adrian _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
