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

[Greg Clayton]

> On Mar 16, 2015, at 6:47 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Mon, Mar 16, 2015 at 5:14 PM, Adrian Prantl <aprantl at apple.com> wrote:
> 
> Thanks for the explanation David, I missed that it is entirely the linker's (or some dwarf post-processor's) responsibility to find the module files and link in the debug info from the .pcm files, so debugger doesn’t notice a difference.
> 
> I think there's still some confusion here. Sorry if I'm rehashing something, but I'll try to explain how this all works.
> 
> Normal split DWARF:
> 
> Compiler generates two files: .o and .dwo. 
> .dwo has static, non-relocatable debug info. 
> .o has a skeleton compile_unit that has the name of the .dwo file and a hash to verify that the .dwo file isn't stale when the debugger reads it.
> The .o files are all linked together, the .dwo files stay where they are.
> The debugger reads the linked executable, finds the skeleton compile_units contained therein, and find/loads the .dwo files
> 
> The scenario I have in mind for module debug info is this:
> Module is compiled as an object file with debug info (this file is actually a .dwo file, even if it has some other extension - it has the non-relocatable debug info in it)
> .o file has a comdat'd skeleton compile_unit describing the .dwo/module file
> <from here on no extra work is required, the linker and debugger just act as normal>
> The .o files are linked together, the skeleton compile_units get deduplicated by the linker (comdat sections)

One issue I can think of is we will need to figure out a way to make COMDAT work with mach-o. COMDAT requires large number of sections and mach-o can only have 255. 

> The debugger reads the linked executable, finds the skeleton compile_units contained therein, and find/loads the module files just as .dwo files.
> 
> There's no need for a debug-aware linker or any DWARF post-processing so far as I understand it. No module-linking is required. Debugger reads the modules directly, just as if they were .dwo files - they're just object files in the filesystem like any other (that they have a different extension isn't too important).
> 
> Does this make sense?

It does. Linking the DWARF for a binary (merging the .o file DWARF with all module debug info) would still be nice for long term storage on build servers so there are no external dependencies or anything that can do stale so that there isn't any loss of debug info in the future.