<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 24, 2014 at 11:20 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> On Nov 24, 2014, at 9:22 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>> The debug info in foo.o will look like this::<br>
>><br>
>>  .debug_info.dwo<br>
><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>
</span>Just to be sure, could you clarify what exactly would go into these skeletons? I’m a little worried that this may increase the size of the .o files quite a bit and thus eat into our performance gains.<br></blockquote><div><br></div><div>Just the basic fission stuff, in this case I think it would just be an abbreviation (which we could also comdat fold) and a single CU:<br><br><div>DW_TAG_compile_unit [1]  </div><div>  DW_AT_GNU_dwo_name [DW_FORM_strp] ( .debug_str[0x00000000] = "foo.dwo")</div><div>  DW_AT_comp_dir [DW_FORM_strp]     ( .debug_str[0x00000008] = "/tmp/dbginfo")</div><div>  DW_AT_GNU_dwo_id [DW_FORM_data8]  (0xbc33964b89b37bb0)<br><br>There shouldn't be a need for a line table if the (non-dwo) CU has no decl_file attributes (which it won't, because it won't have anything other than the DW_TAG_compile_unit tag).<br><br>You could attach your fancy-modules tags (for reconstituting ASTs, etc) to either this CU or to the 'full' CU in the .dwo file/module (if you attach them here, then you save the DWARF consumer from having to read more DWARF in the module/dwo entirely for now (when we have real code in modules that's linked in, you won't be able to make that shortcut - since some of the DWARF you'll still actually need, even if you go to the AST file for most of the types, etc))<br></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class="">><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>
</span>At least as far as LLDB is concerned, it currently doesn’t support fission at all, so we will have to start fresh there anyway.<br></blockquote><div><br></div><div>Sure, but even for LLDB there might be some benefit in starting with fewer moving parts - implementing existing Fission first where already have known-good output from LLVM (in the sense that GDB can correctly consume it) - but I do realize this is perhaps not a very strong argument/motivation.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><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>
</span>Given our plans for a more efficient “bag of dwarf”+index format, which will need work on the consumer side anyway, I’m leaning more towards the latter, but I can see the attractiveness of having a format that works with existing dwarf consumers out-of-the-box. It looks like that the pure fission format would make a better default for platforms that use, e.g., gdb as their default debugger.<br></blockquote><div><br>At least initially it'll be easier for GDB since it already works there. We might want to take advantage of it in GDB too if there's a big savings to be had (or if it'll be a long time before we're linking in object files from modules - we could have the savings in the interim until we have to move debug info for modules back into the linked executable anyway) because there are many modules that don't have any actual code or globals to link into the final executable.<br><br>- David<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
-- adrian<br>
><br>
> Opinions?<br>
><br>
<br>
</blockquote></div><br></div></div>