Re: PATCH: Fix linker plugin support for gnu linker

[Ian Lance Taylor <iant at google dot com>]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Wed, Jan 5, 2011 at 8:47 AM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hongjiu.lu@intel.com> writes:
>>
>>> This patch fixes linker plugin support for gnu linker with 2 stage
>>> linking and supports mixed LTO objects:
>>
>> For the record, I repeat my objections to 2 stage linking and suggest
>> instead implementing my alternate approach described here:
>>
>> http://gcc.gnu.org/ml/gcc/2010-12/msg00347.html
>>
>
> While I consider that is a hack, I don't object it since it
> can co-exist with 2 stage linking.  Gold can implement
> your approach and I will keep 2 stage linking in bfd linker
> in the Linux binutils.
>
> With 2 stage linking, everything just works. It works
> with the current and future GCC.  It does require an extra
> pass. But the first pass is simple and the second pass is
> very straight forward.  The additional linker time only takes a
> very small percentage in the whole LTO linking process.

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.

(As Cary said, an even better adjustment would be to track the complete
set of possible new symbol references, and note where the definition can
be found.  However, I believe that will be harder to maintain over time
than the patch I've already written.  I'm open to pursuing that approach
if people think it would be preferable.)

If my patch is adopted, then I don't see any reason not to adopt the
same approach in the GNU linker.  It would only require adding support
for the new plugin entry point, which should not be hard.

If we go with the 2 stage linking approach, then we might as well
radically simplify the plugin interface.  Almost all the current hooks
can go away.  We only need to pass each input file to the plugin, and
have the plugin pass back which old and which new files should be
included in the second link.

It's true that with the GNU linker the additional linker time is small
percentage-wise.  With gold I expect that it would be a larger
percentage, because gold is a faster linker overall.  And in any case I
don't think that the fact that a speed decrease is small percentage-wise
is a strong argument that the decrease is irrelevant.

Ian