<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 23, 2016 at 2:32 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I think the "take the address" part is the crucial hint. Can't you tell<br>
> from the combination of visibility and relocations what functions are<br>
> safe to merge? The only tricky part I can imagine is identifying<br>
> vtables, as they do not classify as pointer leak.<br>
<br>
</span>Somewhat. Gold has that on its list of heuristics, but it is pretty<br>
nasty. In particular, using files compiled with -fPIC to produce<br>
regular executables breaks the heuristic.<br>
<br>
Lets focus on the non-safe version for now. When time comes I think<br>
the correct thing to do is to implement the nop padding as it is<br>
always safe and then propose adding a flag to ELF to say that a<br>
particular section/symbol doesn't need an unique address.<br></blockquote><div><br></div><div>Yeah. The compiler already knows the this information. No need for the linker to bend over backward to try to recover it.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Rafael<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>