<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 21, 2014 at 5:52 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Plans for module debugging<br>
==========================<br>
<br>
I recently had a chat with Eric Christopher and David Blaikie to discuss ideas for debug info for Clang modules and this is what we came up with.<br>
<br>
Goals<br>
-----<br>
<br>
Clang modules [1], (and their siblings C++ modules and precompiled header files) are a method for improving compile time by making the serialized AST for commonly-used headers files directly available to the compiler.<br>
<br>
Currently debug info is totally oblivious to this, when the developer compiles a file that uses a type from a module, clang simply emits a copy of the full definition (some exceptions apply for C++) of this type in DWARF into the debug info section of the resulting object file. That's a lot of copies.<br>
<br>
The key idea is to emit DWARF for types defined in modules only once, and then only emit references to these types in all the individual compile units that import this module. We are going to build on the split DWARF and type unit facilities provided by DWARF for this. DWARF consumers can follow the type references into module debug info section quite similar to how they resolve types in external type units today. Additionally, the format will allow consumers that support clang modules natively (such as LLDB) to directly look up types in the module, without having to go through the usual translation from AST to DWARF and back to AST.<br>
<br>
The primary benefit from doing all this is performance. This change is expected to reduce the size of the debug info in object files significantly by<br>
- emitting only references to the full types and thus<br>
- implicitly uniquing types that are defined in modules.<br>
The smaller object files will result in faster compile times and faster llvm::Module load times when doing LTO. The type uniquing will also result in significantly smaller debug info for the finished executables, especially for C and Objective-C, which do not support ODR-based type uniquing. This comes at the price of longer initial module build times, as debug info is emitted alongside the module.<br>
<br>
Design<br>
------<br>
<br>
Clang modules are designed to be ephemeral build artifacts that live in a shared module cache. Compiling a source file that imports `MyModule` results in `Module.pcm` to be generated to the module cache directory, which contains the serialized AST of the declarations found in the header files that comprise the module.<br>
<br>
We will change the binary clang module format to became a container (ELF, Mach-O, depending on the platform). Inside the container there will be multiple sections: one containing the serialized AST, and ones containing DWARF5 split debug type information for all types defined in the module that can be encoded in DWARF. By virtue of using type units, each type is emitted into its own type unit which can be identified via a unique type signature. DWARF consumers can use the type signatures to look up type definitions in the module debug info section. For module-aware consumers (LLDB), we will add an index that maps type signatures directly to an offset in the AST section.<br>
<br>
For an object file that was built using modules, we need to record the fact that a module has been imported. To this end, we add a DW_TAG_compile_unit into a COMDAT .debug_info.dwo section that references the split DWARF inside the module. Similar to split DWARF objects, the module will be identified by its filename and a checksum. The imported unit also contains a couple of extra attributes holding all the information necessary to recreate the module in case the module cache has been flushed. Platforms that treat modules as an explicit build artifact do not have this problem. In the .debug_info section all types that are defined in the module are referenced via their unique type signature using DW_FORM_ref_sig8, just as they would be if this were types from a regular DWARF type unit.<br>
<br>
Example<br>
-------<br>
<br>
Let's say we have a module `MyModule` that defines a type `MyStruct`::<br>
$ cat foo.c<br>
#include <MyModule.h><br>
MyStruct x;<br>
<br>
when compiling `foo.c` like this::<br>
clang -fmodules -gmodules foo.c -c<br>
<br>
clang produces `foo.o` and an ELF or Mach-O container for the module::<br>
/path/to/module-cache/MyModule.pcm<br>
<br>
In the module container, we have a section for the serialized AST and a split DWARF sections for the debug type info. The exact format is likely still going to evolve a little, but this should give a rough idea::<br>
<br>
MyModule.pcm:<br>
.debug_info.dwo:<br>
DW_TAG_compile_unit<br>
DW_AT_dwo_name ("/path/to/MyModule.pcm")<br>
DW_AT_dwo_id ([unique AST signature])<br>
<br>
DW_TAG_type_unit ([hash for MyStruct])<br>
DW_TAG_structure_type<br>
DW_AT_signature ([hash for MyStruct])<br>
DW_AT_name “MyStruct”<br>
...<br>
<br>
.debug_abbrev.dwo:<br>
// abbrevs referenced by .debug_info.dwo<br>
.debug_line.dwo:<br>
// filenames referenced by .debug_info.dwo<br>
.debug_str.dwo:<br>
// strings referenced by .debug_info.dwo<br>
<br>
.ast<br>
// Index at the top of the AST section sorted by hash value.<br>
[hash for MyStruct] -> [offset for MyStruct in this section]<br>
...<br>
// Serialized AST follows<br>
...<br>
<br>
The debug info in foo.o will look like this::<br>
<br>
.debug_info.dwo<br></blockquote><div><br>(so if this goes in debug_info.dwo then it would be in foo.dwo, not foo.o... but I had some further thoughts about this... )<br><br>So - imagining a future in which modules are real object files that get linked into the final executable because they contain things like definitions of linkonce_odr functions (so that any object file that has all the linkonce_odr calls inlined doesn't have to carry around a (probably duplicate) definition of the function) - then that object file could also contain the skeleton CU unit (& associated line table, string table, etc) for not only these functions, but for all the types, etc, as well.<br><br>In that world, we would have exactly fission, nothing new (no two-level fission, where some static-data-only skeletons appear in the .dwo file and the skeletons with non-static data (ie: with relocations, such as those describing concrete function definitions or global variables) appear in the .o file).<br><br>We can reach that same output today by adding these skeletons into the .o file (in debug_info, not debug_info.dwo) and using comdat to unique them during linking. <br><br>This option would be somewhat wasteful for now (& in the future for any module that had /no/ concrete code that could be kept in the module - such as would be the case in pure template libraries with no explicit instantiation decl/defs, etc) because it would put module references in the .o, but it would mean not having to teach tools new fission tricks immediately.<br><br>Then, if we wanted to add an optimization of double-indirection fission (having skeleton CUs in .dwo files that reference further .dwo files) we could do that as a separate step on top.<br><br>It's just a thought - Maybe it's an unnecessary extra step and we should just go for the double-indirection from the get-go, I'm not sure?<br><br>Opinions?<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
DW_TAG_compile_unit<br>
// For DWARF consumers<br>
DW_AT_dwo_name ("/path/to/module-cache/MyModule.pcm")<br>
DW_AT_dwo_id ([unique AST signature])<br>
<br>
// For LLDB / dsymutil so they can recreate the module<br>
DW_AT_name “MyModule"<br>
DW_AT_LLVM_system_root "/"<br>
DW_AT_LLVM_preprocessor_defines "-DNDEBUG"<br>
DW_AT_LLVM_include_path "/path/to/MyModule.map"<br>
<br>
.debug_info<br>
DW_TAG_compile_unit<br>
DW_TAG_variable<br>
DW_AT_name "x"<br>
DW_AT_type (DW_FORM_ref_sig8) ([hash for MyStruct])<br>
<br>
<br>
Type signatures<br>
---------------<br>
<br>
We are going to deviate from the DWARF spec by using a more efficient hashing function that uses the type's unique mangled name and the name of the module as input. For languages that do not have mangled type names or an ODR, we will use the unique identifiers produces by the clang indexer (USRs) as input instead.<br>
<br>
Extension: Replacing type units with a more efficient storage format<br>
--------------------------------------------------------------------<br>
<br>
As an extension to this proposal, we are thinking of replacing the type units within the module debug info with a more efficient format: Instead of emitting each type into its own type unit (complete with its entire declcontext), it would be much more more efficient to emit one large bag of DWARF together with an index that maps hash values (type signatures) to DIE offsets.<br>
<br>
Next steps<br>
----------<br>
<br>
In order to implement this, the next steps would be as follows:<br>
1. Change the clang module format to be an ELF/Mach-O container.<br>
2. Teach clang to emit debug info for module types (e.g., by passing an empty compile unit with retained types to LLVM) into the module container.<br>
3a. Add a -gmodules switch to clang that triggers the emission of type signatures for types coming from a module.<br>
3b. Implement type-signature-based lookup in llvm-dsymutil and lldb.<br>
4a. Emit an index that maps type signatures to AST section offsets into the module container.<br>
4b. Implement direct loading of AST types in lldb.<br>
5a. Improve the efficiency by replace type units in the module debug info with a lookup table that maps type signatures to DIE offsets.<br>
5b. Support this format in lldb and llvm-dsymutil.<br>
<br>
Let me know what you think!<br>
<br>
cheers,<br>
Adrian<br>
<br>
[1] For more details about clang modules see<br>
<a href="http://clang.llvm.org/docs/Modules.html" target="_blank">http://clang.llvm.org/docs/Modules.html</a> and<br>
<a href="http://clang.llvm.org/docs/PCHInternals.html" target="_blank">http://clang.llvm.org/docs/PCHInternals.html</a><br>
<br>
</blockquote></div><br></div></div>