Re: PATCH: Fix linker plugin support for gnu linker

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

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.