Update LTO plugin interface

[H.J. Lu]

2010/12/1 Jan Hubicka <hubicka@ucw.cz>:
>> 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.
>
> Hmm and when I have something like
>
> ctrX.o non-lto1.o lto1.o non-lto2.o lto2.o .... crtX.o
> and then linker plugin produce ltrans0.o combining both lto1.o and lto2.o, ho
> we will deal with non-lto2.o?
>

My current implementation groups all LTO files together and linker will see

ctrX.o non-lto1.o ltrans0.o non-lto2.o .... crtX.o

-- 
H.J.