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

>Not quite sure what you mean by "on linker side" - but I guess you
mean using linker features like comdats etc, rather than DWARF
parsing/reassembly/etc.

I mean that it probably not a good idea for external library. I feel it is much
more convinent to do such proccessing in a linker.

Linker do and knows much more about things like sections that are ICFed,
eliminated, about COMDATs and many things like strings dedups.

So it can rebuild relocations and perform DWARF deduplication probably in a
faster/more convinent way probably than external API could provide.

Honestly I did not yet think about it too much, just current feelings.


Geоrge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171215/12a07ad9/attachment.html>

On Fri, Dec 15, 2017 at 7:47 AM George Rimar <grimar at accesssoftek.com>
wrote:
> >Not quite sure what you mean by "on linker side" - but I
guess you mean
> using linker features like comdats etc, rather than DWARF
> parsing/reassembly/etc.
>
>
> I mean that it probably not a good idea for external library. I feel it
> is much more convinent to do such proccessing in a linker.
>
Ah, a matter of where the logic is implemented.

My concern is that we already have one use of this logic (dsymutil) and at
least two other places that could benefit from it (lld and dwp) - it would
seem unfortunate to build and maintain 3 separate versions of this.

(also, possibly one day, a 4th place: llvm IR linking - it could be useful
to generate type DWARF (& CodeView) from frontends rather than backends,
then do a full DWARF aware linking of it in the llvm linking step)

But all of that's probably a bit of a long way off I imagine, in terms of
getting the initial idea (should lld grow/have DWARF aware linking
functionality) going.
> Linker do and knows much more about things like sections that are ICFed,
> eliminated, about COMDATs and many things like strings dedups.
>
> So it can rebuild relocations and perform DWARF deduplication probably in
> a faster/more convinent way probably than external API could provide.
>
> Honestly I did not yet think about it too much, just current feelings.
>
Fair, fair.

- Dave
>
> Geоrge.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171215/73661c93/attachment.html>

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

On Fri, Dec 15, 2017 at 7:47 AM, George Rimar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> >Not quite sure what you mean by "on linker side" - but I
guess you mean
> using linker features like comdats etc, rather than DWARF
> parsing/reassembly/etc.
>
>
> I mean that it probably not a good idea for external library. I feel it
> is much more convinent to do such proccessing in a linker.
>
> Linker do and knows much more about things like sections that are ICFed,
> eliminated, about COMDATs and many things like strings dedups.
>
> So it can rebuild relocations and perform DWARF deduplication probably in
> a faster/more convinent way probably than external API could provide.
>
> Honestly I did not yet think about it too much, just current feelings.
>
>
> Geоrge.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171215/df6b4c05/attachment.html>

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

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