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

>Postprocessing (ie: running a tool on the fully linked binary with the debug
info we have today, and having the tool reprocess the debug info to make it more
>compact) is an option, but wouldn't help address the problem you started
with - that the output can't fit the large offsets, so the output is
invalid/broken. So that >output would be broken before the postprocessing
step could run to compact things.

Right. So then it could be some API that takes .debug_* sections from linker,
takes relocations, additional info,

like info about GCed/ICFed sections. It could rebuild debug data, rebuild
relocations and return it back to linker,

so it could take deduplicated debug info, perform updated relocations and
produce output.


Does not feel nice honestly. It is definetely seems easier to do all of that on
linker side instead.


George.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171208/3488aca7/attachment.html>

On Fri, Dec 8, 2017 at 1:09 AM George Rimar <grimar at accesssoftek.com>
wrote:
> >Postprocessing (ie: running a tool on the fully linked binary with the
> debug info we have today, and having the tool reprocess the debug info to
> make it more >compact) is an option, but wouldn't help address the
problem
> you started with - that the output can't fit the large offsets, so the
> output is invalid/broken. So that >output would be broken before the
> postprocessing step could run to compact things.
>
>
> Right. So then it could be some API that takes .debug_* sections from
> linker, takes relocations, additional info,
>
> like info about GCed/ICFed sections. It could rebuild debug data, rebuild
> relocations and return it back to linker,
>
> so it could take deduplicated debug info, perform updated relocations and
> produce output.
>
Right - this is what COFF does, I believe.
> Does not feel nice honestly.
>
*nod* it's certainly not the direction DWARF's generally gone in, but I
think we're seeing some of the limitations of using a DWARF-agnostic
linking strategy. All attempts I've seen to allow a linker to deduplicate
DWARF without being DWARF aware have added a fair bit of overhead to the
DWARF itself - admittedly there's more options/improvements to be tested,
but it still feels like we'd ultimately find it insufficient & want to
go
further than is possible while the linker remains unaware of
DWARF.
>
> It is definetely seems easier to do all of that on linker side instead.
>
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.
>
>
> George.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171214/1ea73d37/attachment-0001.html>

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