<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 8, 2017 at 1:09 AM George Rimar <<a href="mailto:grimar@accesssoftek.com">grimar@accesssoftek.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p><span style="color:rgb(33,33,33);font-size:12pt">>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.</span><br>
</p>
<p><br>
</p>
</div><div dir="ltr" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif"><p>Right. So then it could be some API that takes .debug_* sections from linker, takes relocations, additional info,<br>
</p>
<p>like info about GCed/ICFed sections. It could rebuild debug data, rebuild relocations and return it back to linker,<br>
</p>
<p>so it could take deduplicated debug info, perform updated relocations and produce output.<br></p></div></blockquote><div>Right - this is what COFF does, I believe. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif"><p>
</p>
<p><span style="font-size:12pt">Does not feel nice honestly. </span></p></div></blockquote>*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. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif"><p><span style="font-size:12pt">It is definetely seems easier to do all of that on linker side instead.</span></p></div></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif"><p><br></p></div><div dir="ltr" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p><br>
</p>
<p>George.<br>
</p>
<p><br>
</p>
<p><br>
</p>
</div></blockquote></div></div>