[PATCH] D17252: [ELF, Bug 26360] - allows undefines that are referenced from garbage collected sections.

[Rui Ueyama via llvm-commits]

On Wed, Feb 17, 2016 at 1:27 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> grimar added a comment.
>
> In http://reviews.llvm.org/D17252#353691, @ruiu wrote:
>
> > I think that we don't want it until it is proved that this "feature" is
> really needed.
> >
> > 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.
>
>
> 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.
> Also I found that "It is ok for dead code to reference undefined
> symbols..." (
> http://lists.llvm.org/pipermail/llvm-dev/2015-June/086571.html). From my
> POV it was mentionaed as a expected and desired feature.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160217/7ded31d1/attachment.html>