[PATCH] D74169: [WIP][LLD][ELF][DebugInfo] Skeleton implementation of removing obsolete debug info.

Mon Feb 24 11:25:53 PST 2020

clayborg added a comment.

In D74169#1889749 <https://reviews.llvm.org/D74169#1889749>, @dblaikie wrote:

> In D74169#1888386 <https://reviews.llvm.org/D74169#1888386>, @clayborg wrote:
>
> > In D74169#1887799 <https://reviews.llvm.org/D74169#1887799>, @dblaikie wrote:
> >
> > > In D74169#1887791 <https://reviews.llvm.org/D74169#1887791>, @clayborg wrote:
> > >
> > > > In D74169#1887764 <https://reviews.llvm.org/D74169#1887764>, @dblaikie wrote:
> > > >
> > > > > lld already supports gdb_index & there's plans to add debug_names support in the near future (~6 months).
> > > >
> > > >
> > > > Does it support adding the GDB index after the fact on an already linked binary, or just at normal link time? I want to add a GSYM option to LLD at some point too. Can replace -gline-tables-only in many cases.
> > >
> > >
> > > I don't think there's been any effort to add it as a post-processing step, no. I believe it can be built either from parsed DWARF or from debug_gnu_pubnames - in either case, at link time.
> >
> >
> > is debug_gnu_pubnames a new section that is now complete? The old .debug_pub* sections only contained globally visible things which means all debuggers would ignore this section. If accelerator tables were made from incomplete sources that will mean debuggers will have to question if .debug_names is complete or not.
>
>
> It's "complete" in the sense that it's whatever GDB wanted and created a contract that GCC (& Clang/LLVM as best we know/have done so far) agree too, so GDB can rely on things being present/not present in some sense.
>
> That's why debug_gnu_pubnames existed - because of, as you say, the underspecified nature of (or unreliable implementation of) debug_pubnames.

Perfect, that is what I was hoping for.

> I believe debug_names semantics have been more strictly specified regarding what names will be there and what names will not.

Yes, it indeed fully specifies what is needed. Thanks for the info.

> 
> 
>>> I mean, it'd be probably quite practical to extend it to be able to be done as a standalone/post-processing step.
>> 
>> That would be great. As accelerator tables evolve and get updated, it would be nice to have a path to update older accelerator tables to newer more complete versions.
>> 
>>> For the sake of object and linked executable size, I suspect we might end up trying to move the indexing out of the object files/linked executable - perhaps putting the names either in a third file, or in the .dwo files and generating an index from them instead of from the objects. Not sure. Some further experimentation expected there.
>> 
>> That is fine too. We make a dwarf linking tool that can link all of the .dwo files back into a normal DWARF file like with dsymutil and .o files on mac.
> 
> That's already done - DWP ( https://gcc.gnu.org/wiki/DebugFissionDWP ). But for an interactive scenario over a distributed filesystem shipping the whole linked DWP file back to the user for access by the debugger is a bit unfortunate/slow. Good for archival purposes, as you say - but it's still a bit of an open question as to what to do for interactive users if object file/linked executable size is a major concern - either generating a third file with just the index parts (so building the full index can be done in parallel/distributed separately from the link) or doing an index-only link of the .dwo files (not super great - still means a bottleneck of shipping all the .dwo files to one build machine, etc)...

For the linking, I was more thinking of converting the DWP format back into vanilla DWARF with no DWO/DWP artifacts (skeleton DIEs etc) or any other redirections (string table offsets, address tables, etc). Not sure if this would reduce the DWARF size of all of the DWO/DWP instrstructure was all removed?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74169/new/

https://reviews.llvm.org/D74169