<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 17, 2015, at 6:44 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Mar 17, 2015 at 3:47 PM, Adrian Prantl <span dir="ltr" class=""><<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br class="">
> On Mar 17, 2015, at 10:03 AM, Greg Clayton <<a href="mailto:gclayton@apple.com" class="">gclayton@apple.com</a>> wrote:<br class="">
><br class="">
><br class="">
>> On Mar 17, 2015, at 9:46 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:<br class="">
>><br class="">
>><br class="">
>><br class="">
>> On Tue, Mar 17, 2015 at 9:42 AM, Greg Clayton <<a href="mailto:gclayton@apple.com" class="">gclayton@apple.com</a>> wrote:<br class="">
>><br class="">
>>> On Mar 16, 2015, at 6:47 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:<br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>> On Mon, Mar 16, 2015 at 5:14 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" class="">aprantl@apple.com</a>> wrote:<br class="">
>>><br class="">
>>> 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 class="">
>>><br class="">
>>> 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 class="">
>>><br class="">
>>> Normal split DWARF:<br class="">
>>><br class="">
>>> Compiler generates two files: .o and .dwo.<br class="">
>>> .dwo has static, non-relocatable debug info.<br class="">
>>> .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 class="">
>>> The .o files are all linked together, the .dwo files stay where they are.<br class="">
>>> The debugger reads the linked executable, finds the skeleton compile_units contained therein, and find/loads the .dwo files<br class="">
>>><br class="">
>>> The scenario I have in mind for module debug info is this:<br class="">
>>> 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 class="">
>>> .o file has a comdat'd skeleton compile_unit describing the .dwo/module file<br class="">
>>> <from here on no extra work is required, the linker and debugger just act as normal><br class="">
>>> The .o files are linked together, the skeleton compile_units get deduplicated by the linker (comdat sections)<br class="">
>><br class="">
>> 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 class="">
>><br class="">
>> Ah, fair enough - how does MachO handle inline functions (the most common use of comdat) currently, then?<br class="">
><br class="">
> Currently mach-o relies on symbols in the symbol table being marked as weak and I believe the data for these symbols are in special sections that are marked as containing items that can be coalesced.<br class="">
><br class="">
</div></div>That’s not necessarily an issue that needs to be solved on Darwin, or am I maybe missing something? The linker leaves all debug info in the .o (as it currently does) and llvm-dsymutil is resolving all the external module type references while creating the .dSYM bundle.<br class=""></blockquote><div class=""><br class="">Yeah, with a debug aware linker (or in the case of dsymutil, a debug-only linker) you would just know that since you're looking at object files, module references will be redundant across objects and should be deduplicated (by the dwo hash, most likely).<br class=""><br class="">If you're not teaching your debugger to read modules, and want to link the debug info in from the .dwos - at that point you can probably drop the skeleton stuff entirely (you'd still need to teach your debugger about .dwo sections and some of the esoteric things there - like str_index and the extra/special line table just for file names (decl_file, etc, uses this)) and just put the contents of the module debug info straight in the dsym. It'd be a bit weird, but do-able without too much work, I'd imagine. You could move them back into the original sections, if you wanted to avoid the weird .dwo +non-.dwo sections together... *shrug* not sure what exactly you'd want there.<br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>My plan was to have -gmodules to behave like the latter variant unless -gsplit-dwarf is also present; this way there wouldn't be any weird Darwin-specific code paths.</div><div><br class=""></div><div>-- adrian</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class="">- David<br class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
-- adrian</font></span></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>