"H.J. Lu" <hjl.to...@gmail.com> writes:
> 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.
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
