[lldb-dev] Plans for module debugging

[David Blaikie]

On Mon, Nov 24, 2014 at 4:26 PM, Eric Christopher <echristo at gmail.com>
wrote:

>
>
> On Mon Nov 24 2014 at 11:20:11 AM Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>> > On Nov 24, 2014, at 9:22 AM, David Blaikie <dblaikie at gmail.com> wrote:
>> >>
>> >> The debug info in foo.o will look like this::
>> >>
>> >>  .debug_info.dwo
>> >
>> > (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... )
>> >
>> > 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.
>> >
>> > 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).
>> >
>> > 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.
>>
>> 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.
>>
>
> FWIW skeletons are very small and completely dwarfed (get it?) by the size
> of the line table or anything else.
>

Yeah, just reserving some judgment until actual numbers/providing an 'out'
if necessary/hedging bets/etc - it was worth removing type unit skeletons
(which, between debug_types and .rela.debug_types made up about 30% of
debug info in .o files) & module skeletons would probably be one or two
orders of magnitude smaller (10-100 public types per module?) that's
something like 4% (for 1:10) or less, probably much less.


>
> -eric
>
>
>> >
>> > 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.
>>
>> 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.
>>
>> >
>> > 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.
>> >
>> > 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?
>>
>> 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.
>>
>> -- adrian
>> >
>> > Opinions?
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141124/376593e9/attachment.html>