This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PATCH: Fix linker plugin support for gnu linker
"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.
> 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.
Richard