PATCH: Fix linker plugin support for gnu linker

[H.J. Lu]

On Wed, Jan 5, 2011 at 11:52 AM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>>> My counter-argument is that the entire linker plugin system was designed
>>> from the start to avoid 2 stage linking.  I don't think my patch is a
>>> hack.  I think it is an appropriate adjustment to handle an unusual case
>>> which the original plugin design did not consider: new symbol references
>>> inserted by the compiler which were not present in the original code.
>>
>> My counter-argument is "an unusual case" isn't that unusual.
>
> It seems to me to be fairly unusual.  Most test cases are working fine
> without either of our patches.  The only cases that fail are when
> linking libc or libm or libgcc statically, which is in itself uncommon
> these days, in combination with certain very specific optimizations
> which only occur for some code.

We can agree to disagree.

>
>> Avoiding  2 stage linking makes the whole LTO infrastructure
>> unnecessarily more complex.
>
> But, I want to say this carefully and I hope that you will read it
> carefully, that work has already been done and was part of the linker
> plugin design from the very beginning.  Yes, it is more complex.  But
> the work has already been done and it is already working.  Except for
> this rather unusual case, and I have already shown how a simple and
> small extension to the plugin design accounts for this case as well.

By the same token, I have implemented 2 stage linking in GNU linker
and it works with the current linker plugin ABI.

If you think this is a "rather unusual case" and the current
design/implementation works for majority cases, I don't see
big problems for GNU linker to do 2 stage linking and gold keeps
the current behavior.


-- 
H.J.