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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D74169#1878422 <https://reviews.llvm.org/D74169#1878422>, @MaskRay wrote:

> I agree with
>
> > if the additional complexity is not too much, and the new code is nicely isolated from existing code. I think I agree with you that linker is perhaps the best place to drop dead DWARF info.
>
> (One thing I plan to work on is .debug_names accelerator table, which is similar to but more power than `.gdb_index`.)
>
> On one side, I've heard thoughts that: 
>  (1) if we use -gsplit-dwarf, is .debug* garbage collection still valuable?


For users using -gsplit-dwarf, linker garbage collection provides zero value. But not everyone does, there are reasons to use one or the other in different situations.

> (2) DWARFLinker can significantly increase link time. Can we move it to a post-link tool (dsymutil but for ELF)?

Presumably that'd take significantly longer and use more memory and disk space overall - but, yes, it would get you a running executable sooner. (/somewhat/ like the tradeoff of using .dwo files directly, compared to linking them into a .dwp - dwo files are ready sooner, but take up more space, etc, but dwp takes time to make - good for archival purposes)

But (2) I think is unclear to me - I'd like to know how much more time/memory it takes, if it does take more (it probably will take more) - given that it should produce significantly less output (& at Google at least, output is memory usage - since we write to a memory mapped file (though we use Split DWARF in most places where size/memory usage matters, so this solution isn't immediately relevant there).

(& this also might be reusable/good foundation for DWARF aware linking in llvm-dwp, for what it's worth (again, not clear what the tradeoffs will be like in terms of memory/cpu overhead, output size savings, etc))

> On the other side, I think this approach may be better than D54747 <https://reviews.llvm.org/D54747> (reverted by rL360955 <https://reviews.llvm.org/rL360955>) and may address the problem it tried to mitigate. Given the savings, we may bend our mind a bit and give more tolerance even if the additional complexity is more than `not too much`.
> 
> I am reluctant to let individual patches in before we can see the benefits, because they could easily turn out to be insufficient and cause churns. There is still possibility that we find --gc-debuginfo not suitable on the linker side and may want to do it in a post-link tool.





================
Comment at: lld/ELF/LLDDwarfLinker.cpp:74-75
+
+      dwarfContexts.push_back(std::unique_ptr<DWARFContext>(
+          new DWARFContext(std::make_unique<LLDDwarfObj<ELFT>>(obj))));
+
----------------
Probably should be using make_uniqeu<DWARFContext> too, rather than "unique_ptr(new DWARFContext"?

(& a couple of other opportunities to use make_unique in this code below)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74169