<br><br><div class="gmail_quote">On Mon Nov 24 2014 at 11:20:11 AM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Nov 24, 2014, at 9:22 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">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>
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>FWIW skeletons are very small and completely dwarfed (get it?) by the size of the line table or anything else.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><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>
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>
<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>
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>
<br>
-- adrian<br>
><br>
> Opinions?<br>
><br>
<br>
</blockquote></div>