Update LTO plugin interface

Richard Guenther richard.guenther@gmail.com
Wed Dec 1 21:33:00 GMT 2010


On Wed, Dec 1, 2010 at 10:28 PM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>>
>>>> On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor <iant@google.com> wrote:
>>>>
>>>>> Are you planning to have the plugin claim all files, even linker
>>>>> scripts, and then pass only the command line files back to the linker?
>>>>>
>>>>
>>>> Plugin will keep the same claim strategy.  For those aren't claimed by
>>>> plugin, plugin will save and pass them back to linker only if they are
>>>> specified at command line.
>>>
>>> Just to be clear, that does not make sense as written.  If the plugin
>>> does not claim a file, it should not then pass it back to the linker.
>>
>> API has
>>
>> typedef
>> enum ld_plugin_status
>> (*ld_plugin_claim_file_handler) (
>>   const struct ld_plugin_input_file *file, int *claimed);
>>
>> For linker script, archive, DSO and object file without IR,
>> *claimed will return 0 and plugin will save and pass it back to
>> linker later in  if it is specified at command line.
>
> I don't understand what you wrote, so I am going to write what I think
> happens.
>
> The claim_file handler is an interface provided by the plugin itself.
> The plugin will register it via LDPT_REGISTER_CLAIM_FILE_HOOK.  The
> linker proper will call it for each input file.
>
> In the case of the LTO plugin, this is the static function
> claim_file_handler in lto-plugin.c.
>
> If the plugin registers a claim_file handler, and, when the linker calls
> it, it returns with *claimed == 0, then the linker will process the file
> as it normally does.  Since the file will already have been processed,
> it does not make sense for the plugin to then pass it back to the
> linker.  The effect would be similar to listing the file twice on the
> command line.

The basic problem is that if lto-plugin claims a file and provides a symtab
to the linker the link-time optimization might change that, including
adding new undefined symbols (think of libcalls).  The linker needs
to re-process even not-claimed static archives (such as libgcc) to
resolve those new undefs.  We hack around this by adding another
-lgcc at the end of the command-line, but that does change linker
resolution as the link order does matter.

Basically we need to trigger a complete re-link with the claimed
object files substituted for the link-time optimized ones.

Richard.

>
>>> In fact, if the plugin claims all files, then as far as I can see your
>>> new ld_plugin_input_file field is not required.  And if the plugin does
>>> not claim all files, I don't see how this can work.
>>
>> Stage 2 linker should:
>>
>> 1. Discard all previous inputs.
>
> How is this step done?
>
>
>> My implementation is available on hjl/lto branch at
>
> Thanks, but I don't see any changes to gold there, so I don't see what
> you have done to change the plugin interface.
>
> Ian
>



More information about the Binutils mailing list