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

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

On Fri, Jan 28, 2011 at 6:01 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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.
>


I run your patch on those new LTO tests. I got relevant failures:

FAIL: LTO 2
FAIL: LTO 11
FAIL: LTO 8

Your patch doesn't fix any failures and introduce a new one.

-- 
H.J.