PATCH: Fix linker plugin support for gnu linker

[H.J. Lu]

On Sat, Jan 8, 2011 at 6:46 AM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>> On Sat, Jan 8, 2011 at 4:10 AM, Richard Sandiford
>> <rdsandiford@googlemail.com> wrote:
>>> "H.J. Lu" <hongjiu.lu@intel.com> writes:
>>>> This patch fixes linker plugin support for gnu linker with 2 stage
>>>> linking and supports mixed LTO objects:
>>>>
>>>> http://www.kernel.org/pub/linux/devel/gcc/lto/mixed-IR/mixed-IR.pdf
>>>>
>>>> Any objections?
>>>
>>> One problem with the patch as written is that it doesn't cope with
>>> the kind of embedded setup in which the startup file is specified
>>> in a linker script.  E.g. on mipsisa64-elf, GCC doesn't know what
>>> system you're targetting, and therefore doesn't what startup files or
>>> board-specific libraries are needed.  You instead link with something
>>> like -Tidt64.ld.  idt64.ld then contains:
>>>
>>> STARTUP(crt0.o)
>>>
>>> -T options are parsed immediately in-place, and don't show up in the
>>> cmdline_options.  Things like STARTUP don't either.  This means that
>>> crt0.o is dropped by the second stage link.
>>>
>>> The handling of -T also means that the system libraries:
>>>
>>> GROUP(-lc -lidt -lgcc)
>>>
>>> don't show up in the second link.  However, that brings up a broader
>>> question (which might already have been answered, sorry).  The current
>>> process -- that is, the process before the 2-stage patch -- seems to
>>> rely on the GCC driver passing the equivalent of:
>>>
>>>  -pass-through=-lgcc -pass-through=-lc -pass-through=-lgcc
>>>
>>> to the plugin.  But on targets like mipsisa64-elf, GCC doesn't know
>>
>> hjl/lto-mixed branch ignores  -pass-through=XXX passed from gcc driver.
>
> Right, that's what I meant.  The fact that the 2-pass link doesn't
> need those options means that it would solve the problem for free.
> But at the moment it doesn't work because it ignores the linker script's
> GROUP as well.

You can pass -Wl,--verbose to gcc to see exactly what are passed to
stage 2 linking:

Stage 2 command line:
  /usr/lib/../lib/crt1.o /usr/lib/../lib/crti.o
/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/32/crtbegin.o
/tmp/ccmzgIMd.ltrans0.ltrans.o --no-whole-archive
/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/32/libgcc.a
/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib/libgcc_s.so
/usr/lib/../lib/libc.so --no-whole-archive
/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/32/libgcc.a
/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib/libgcc_s.so
/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/32/crtend.o
/usr/lib/../lib/crtn.o

I just need to handle STARTUP properly.

>> If hjl/lto-mixed branch doesn't work with -Tidt64.ld, please open a bug
>> report.  I will take a  look.
>
> Well, I'd tested the patch by applying it to FSF mainline before
> posting.  What I described was a real failure that I was seeing, not a
> hypothetical objection.  After the patch, any "mipsisa64-elf-gcc -flto
> -Tidt64.ld foo.c" command fails in the way I described, and for the
> reason I described.  The second pass drops crt0.o from the link,
> so the start symbol _start isn't defined.
>

If you can provide a native testcase on Linux/x86-64, I will fix it.

Thanks.

-- 
H.J.