[lldb-dev] Plans for module debugging

[Eric Christopher]

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.

-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/20141125/41d1f070/attachment.html>