Re: Update LTO plugin interface

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

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

> On Wed, Dec 1, 2010 at 1:28 PM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>> 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.

But what does that mean?  Are you saying that the linker interface to
the plugin should change to work that way?  If we do that, then we
should change other aspects of the plugin interface as well.  It could
probably become quite a bit simpler.


The only reason we would ever need to do a complete relink is if the LTO
plugin can introduce arbitrary new symbol references.  Is that ever
possible?  If it is, we need to rethink the whole approach.  If the LTO
plugin can introduce arbitrary new symbol references, that means that
LTO plugin can cause arbitrary objects to be pulled in from archives.
And that means that if we only run the plugin once, we are losing
possible optimizations, because the plugin will never those new objects.


My suspicion is that the LTO plugin can only introduce a small bounded
set of new symbol references, namely those which we assume can be
satisified from -lc or -lgcc.  Is that true?

Ian