This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Update LTO plugin interface


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]