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

[David Blaikie via llvm-dev]

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>