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 10:54 AM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>> Â Â Â b. Compiler plugin controls what linker uses to generate the final executable:
>>> Â Â Â Â Â Â Â i. The linker command line order should be the same, with or without LTO.
>>> Â Â Â c. Add a cmdline bit field to
>>> Â Â Â struct ld_plugin_input_file
>>> Â Â Â {
>>> Â Â Â Â Âconst char *name;
>>> Â Â Â Â Âint fd;
>>> Â Â Â Â Âoff_t offset;
>>> Â Â Â Â Âoff_t filesize;
>>> Â Â Â Â Âvoid *handle;
>>> Â Â Â Â Âunsigned int cmdline : 1;
>>> Â Â Â };
>>
>> Just make it an int. ÂBut I don't see why this is needed. ÂThe plugin
>> already knows the files that it passed to add_input_file and
>> add_input_library. ÂWhy does it need to linker to report back where the
>> file came from? ÂWhy doesn't the plugin just keep track?
>>
>
> It is used to keep the same linker command line order. With LTO,
> linker should use
>
> crtX.o *trans*.o -lbar -lgcc -lc ... crtX.o
>
> instead of
>
> crtX.o -lbar -lgcc -lc ... crtX.o  *trans*.o
>
> to generate final executable.  2 orders may generate different
> executables.

I'm sorry, I'm missing something.  What does adding that bit have to do
with keeping the same linker command line order?

Is your concern that when the plugin adds a new input file to the link,
that new input file does not cause additional objects to be pulled out
of archives later in the link?  At least in gold, what matters for that
is when the plugin calls the add_input_file or add_input_library
callback.  In gold it would be fairly difficult to have that work any
other way.

Ian