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

[David Blaikie]

On Tue, Mar 17, 2015 at 9:42 AM, Greg Clayton <gclayton at apple.com> wrote:

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

Ah, fair enough - how does MachO handle inline functions (the most common
use of comdat) currently, then?


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


Yeah, there's the dwp format for smooshing all the .dwo files together - a
.dwp-creation tool could be easily modified to cope with module files by
dropping the module parts and just keeping the .dwo parts (heck, the
current dwp tool(s?) might already do this by accident - not sure what they
do with unknown sections). Whether you smoosh the .dwp with the executable
is a relatively minor issue then - one file or two, rather than hundreds.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150317/a1e8f959/attachment.html>