Re: Update LTO plugin interface

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Dec 1, 2010 at 11:12 AM, Ian Lance Taylor <iant@google.com> wrote:
> "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?

We don't want to put all unclaimed files passed to plugin back to linker.
On Linux,

[hjl@gnu-6 gcc-lto]$ cat /usr/lib/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED (
/lib/ld-linux.so.2 ) )
[hjl@gnu-6 gcc-lto]$

Linker should use /usr/lib/libc.so, not /lib/libc.so.6,
/usr/lib/libc_nonshared.a,
/lib/ld-linux.so.2,  for final linker.  With the new cmdline field,
plugin can only pass
those unclaimed files from linker command line back to linker for the
final link.

> 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.
>

Please try the testcase in

http://sourceware.org/bugzilla/show_bug.cgi?id=12248#c5

with gold.

-- 
H.J.