[llvm-dev] [RFC] - Deduplication of debug information in linkers (LLD).

George Rimar via llvm-dev llvm-dev at lists.llvm.org
Sat Dec 16 11:27:35 PST 2017


?But could not we for example do split dwarf, but for example do dedup of types ?

I do not mean right now, but in a theory ?


Best regards,
George | Developer | Access Softek, Inc
________________________________
От: David Blaikie <dblaikie at gmail.com>
Отправлено: 16 декабря 2017 г. 22:25
Кому: George Rimar
Копия: Sean Silva; llvm-dev at lists.llvm.org; Rui Ueyama; Rafael Espindola
Тема: Re: [llvm-dev] [RFC] - Deduplication of debug information in linkers (LLD).



On Sat, Dec 16, 2017 at 4:08 AM George Rimar <grimar at accesssoftek.com<mailto:grimar at accesssoftek.com>> wrote:

>Wasn't our (lld/ELF's) position on debug info size that we should focus on providing a great split-dwarf workflow and not try go too far out of our way to deduplicate >or otherwise reduce debug info size inside LLD? I recall there being some patches that made linking of large debug binaries like 1.5GB+ clang faster, but we decided to >reject those changes because split-dwarf was the "right" solution.

>
>Rafael, Rui?
>
>(I even recall Rafael saying at one point that a great split-dwarf workflow was one of the key things he considered as necessary for him to consider LLD "done")
>
>-- Sean Silva

I probably not the right person to suggest (still mostly learning here for now, so would like to be on a fence in general),
but it looks for me that splitting DWARF and deduplicating DWARF is a bit othogonal things.
It feels for me that there is a room to do both things and have a benefit from combinatiion ?

The two features/directions don't really compose - if the DWARF is split, then the linker never sees the DWARF (it's not in the object files), so has no deduplication to do. (llvm-dwp might see it, so the deduplication can happen there)


George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171216/a82b9005/attachment.html>


More information about the llvm-dev mailing list