Update LTO plugin interface

[H.J. Lu]

On Wed, Dec 1, 2010 at 1:33 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> 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.
>

That is what my implementation does.


-- 
H.J.