<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 17, 2015 at 9:42 AM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Mar 16, 2015, at 6:47 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Mar 16, 2015 at 5:14 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> I think there's still some confusion here. Sorry if I'm rehashing something, but I'll try to explain how this all works.<br>
><br>
> Normal split DWARF:<br>
><br>
> Compiler generates two files: .o and .dwo.<br>
> .dwo has static, non-relocatable debug info.<br>
> .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.<br>
> The .o files are all linked together, the .dwo files stay where they are.<br>
> The debugger reads the linked executable, finds the skeleton compile_units contained therein, and find/loads the .dwo files<br>
><br>
> The scenario I have in mind for module debug info is this:<br>
> 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)<br>
> .o file has a comdat'd skeleton compile_unit describing the .dwo/module file<br>
> <from here on no extra work is required, the linker and debugger just act as normal><br>
> The .o files are linked together, the skeleton compile_units get deduplicated by the linker (comdat sections)<br>
<br>
</span>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.<br></blockquote><div><br>Ah, fair enough - how does MachO handle inline functions (the most common use of comdat) currently, then?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> The debugger reads the linked executable, finds the skeleton compile_units contained therein, and find/loads the module files just as .dwo files.<br>
><br>
> 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).<br>
><br>
> Does this make sense?<br>
<br>
</span>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.</blockquote><div><br>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. </div></div><br></div></div>