This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH,trunk+2.21.1] Fix link order problem with LD plugin API.


On Fri, Jan 28, 2011 at 5:45 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Jan 28, 2011 at 5:48 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>
>> ? ?Hi list,
>>
>> ?This patch updates the existing plugin API in LD to correct the effective
>> link order of the files added by the plugin. ?(It does not deal with the need
>> for pass-throughs; that is a separate and orthogonal issue that I will tackle
>> in a subsequent patch. ?I hope that the combination of these two fixes should
>> address all the same issues HJ's two-stage linking approach was designed to fix.)
>>
>> ?At the moment added files and libraries are simply concatenated onto the end
>> of the statement list. ?This is more-or-less the same as adding them onto the
>> end of the command-line; this means that their contributions get merged into
>> sections after all the non-IR files, including in particular crtend.o. ?That's
>> pretty serious when it results in something like this:
>>
>>> .eh_frame ? ? ? 0x00404000 ? ? ?0x200
>>> ?*(.eh_frame)
>>> ?.eh_frame ? ? ?0x00404000 ? ? ? 0x58 /gnu/gcc/obj-clean-r169274/gcc/testsuite/g++/../../crtbegin.o
>>> ?.eh_frame ? ? ?0x00404058 ? ? ? 0x5c /gnu/gcc/obj-clean-r169274/gcc/testsuite/g++/../../crtend.o
>>> ?.eh_frame ? ? ?0x004040b4 ? ? ? 0x68 /win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccF5bqWv.lto.o
>>
>> because it breaks EH!
>>
>> ?The attached patch doesn't implement two-stage linking, but takes the
>> approach Cary described(*) in GOLD:
>>
>>> On 03/12/2010 18:46, Cary Coutant wrote:
>>>
>>>> I should have remembered that I already dealt with this problem long
>>>> ago -- gold defers the layout of all real objects that follow the
>>>> first claimed IR file until after the replacement files have been laid
>>>> out. With respect to physical layout of the sections, this effectively
>>>> makes the link order equivalent to putting the replacement files in
>>>> the place of the first IR file. No "endcap" option is necessary.
>>
>> ?In LD, there's nothing to "defer", as layout hasn't begun yet. ?All we need
>> to do is add the replacement files into the middle of the existing statement
>> list, immediately after the first claimed IR file. ?Complicated only slightly
>> by the fact that there are in fact three separate singly-linked chains through
>> the list of statements, that's what this patch does, and it results in the
>> correct result:
>>
>>> .eh_frame ? ? ? 0x00404000 ? ? ?0x200
>>> ?*(.eh_frame)
>>> ?.eh_frame ? ? ?0x00404000 ? ? ? 0x58 /gnu/gcc/obj-clean-r169274/gcc/testsuite/g++/../../crtbegin.o
>>> ?.eh_frame ? ? ?0x00404058 ? ? ? 0x68 /win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccfuGGNR.lto.o
>>> ?.eh_frame ? ? ?0x004040c0 ? ? ? 0x5c /gnu/gcc/obj-clean-r169274/gcc/testsuite/g++/../../crtend.o
>>
>> ld/ChangeLog:
>>
>> 2011-01-29 ?Dave Korn ?<dave.korn.cygwin@gmail.com>
>>
>> ? ? ? ?* ldlang.c (lang_process): After adding and opening new input files
>> ? ? ? ?passed from plugin, splice them into correct place in statement list
>> ? ? ? ?chains to preserve critical link order.
>> ? ? ? ?(lang_list_insert_after): New helper function.
>> ? ? ? ?(lang_list_remove_tail): Likewise.
>>
>> ?Built and tested on i686-pc-cygwin. ?I'm running a subset of the G++/GCC
>> testsuites to sanity-check it as well, and I'll put it through a cycle or two
>> on one of the cfarm machines while I'm at it.
>>
>
> On hjl/lto-mixed branch, I added a dozen LTO tests. ?They are tested
> if GCC supports LTO. ?You should try your ld changes on those new
> LTO tests. ?You can ignore those mixed IR failures. But other LTO tests
> should pass. ?I can post a patch for LTO testcases if you want.
>

Here is the new LTO tests.  The current LD in CVS failed:

FAIL: LTO 2
FAIL: ld-plugin/lto-4r-a
FAIL: ld-plugin/lto-4r-b
FAIL: ld-plugin/lto-4r-c
FAIL: ld-plugin/lto-4r-d
FAIL: LTO 3 symbol
FAIL: LTO 5 symbol
FAIL: LTO 4a
FAIL: LTO 4c
FAIL: LTO 4d
FAIL: LTO 10
FAIL: LTO 8

You can ignore

FAIL: ld-plugin/lto-4r-a
FAIL: ld-plugin/lto-4r-b
FAIL: ld-plugin/lto-4r-c
FAIL: ld-plugin/lto-4r-d
FAIL: LTO 3 symbol
FAIL: LTO 5 symbol
FAIL: LTO 4a
FAIL: LTO 4c
FAIL: LTO 4d
FAIL: LTO 10

But all other tests should pass.


-- 
H.J.

Attachment: ld-lto-test-1.patch
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]