Update LTO plugin interface

H.J. Lu hjl.tools@gmail.com
Wed Dec 1 21:52:00 GMT 2010

On Wed, Dec 1, 2010 at 1: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.

That is what "Discard all previous inputs" in stage 2 linking is for.

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

For GNU linker, I mark all sections in a bfd file, which
will be sent back from plugin, with SEC_EXCLUDE. I also
free and recreate the output hash table.

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

My changes should be visible now.


More information about the Gcc mailing list