Re: PATCH: Fix linker plugin support for gnu linker

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Jan 5, 2011 at 10:33 AM, Ian Lance Taylor <iant@google.com> wrote:
> "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.

My counter-argument is "an unusual case" isn't that unusual.
Avoiding  2 stage linking makes the whole LTO infrastructure
unnecessarily more complex.

>
> 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.

I don't see much benefit not to do 2 stage linking in GNU linker
since

1. It won't improve link time much.
2. We still need to support mixed IR objects.
3. Some "unusual cases" aren't covered.

> 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.
>

I think Gold should do 2 stage linking since

1. It will simplify the whole LTO infrastructure
2. It may be easier to support mixed IR and non-IR inputs.
3. It may cover all "unusual cases".

You can make your first pass simple and fast since you
only need to do symbol resolution.  In the second pass,
you don't have to deal with IR at all.

-- 
H.J.