2010/12/1 Jan Hubicka <hubi...@ucw.cz>:
>> On Wed, Dec 1, 2010 at 10:54 AM, Ian Lance Taylor <i...@google.com> wrote:
>> > "H.J. Lu" <hjl.to...@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.
