<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 17, 2016 at 1:27 AM, George Rimar <span dir="ltr"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">grimar added a comment.<br>
<span><br>
In <a href="http://reviews.llvm.org/D17252#353691" rel="noreferrer" target="_blank">http://reviews.llvm.org/D17252#353691</a>, @ruiu wrote:<br>
<br>
> I think that we don't want it until it is proved that this "feature" is really needed.<br>
><br>
> It is not hard to imagine that this is _not_ a feature of gold's or GNU ld's. Depending on your internal data structure, this behavior could naturally arise. If the same behavior naturally occurred in our linker, it'd be okay, but this patch intentionally mimic the obscure behavior of the other linkers. I think it needs more justification than "because GNU gold/ld do that" to add this code.<br>
<br>
<br>
</span>It was hard to imagine for me though, I was and still thinking about it as about feature. It is not logical for me to keep dependency on code that is dead itself. Keep errors because of undefines that are actually no longer exist because whole section is GCollected.<br>
Also I found that "It is ok for dead code to reference undefined symbols..." (<a href="http://lists.llvm.org/pipermail/llvm-dev/2015-June/086571.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2015-June/086571.html</a>). From my POV it was mentionaed as a expected and desired feature.<br></blockquote><div><br></div><div>As much as it is logical to allow undefined symbols in garbage-collected sections, it is logical to not allow them. The obvious oddity is that --gc-sections would now change the semantics of linking, although it is considered as an optimization in size. I don't think it makes sense to change the current semantics, which is natural one for the LLD architecture, based on a hypothesis. I would be convinced if large codebase depends on the alternative semantics, but I guess it is unlikely, so we should probably focus on what actually matters rather than tweaking semantics of dark corners which no one knows what is the right thing to do.</div></div></div></div>