[lldb-dev] Plans for module debugging

[David Blaikie]

On Mon, Nov 24, 2014 at 11:20 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.
>

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:

DW_TAG_compile_unit [1]
  DW_AT_GNU_dwo_name [DW_FORM_strp] ( .debug_str[0x00000000] = "foo.dwo")
  DW_AT_comp_dir [DW_FORM_strp]     ( .debug_str[0x00000008] =
"/tmp/dbginfo")
  DW_AT_GNU_dwo_id [DW_FORM_data8]  (0xbc33964b89b37bb0)

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).

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))



> >
> > 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.
>

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.


>
> >
> > 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.
>

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.

- David


>
> -- adrian
> >
> > Opinions?
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141124/897028cb/attachment.html>