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 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.

-- 
H.J.