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

[Dave Korn]

    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.

  Assuming all that shows it working, OK to commit this to trunk, and after a
few days to settle in (and submit another plugin-related patch or two) to the
branch?

    cheers,
      DaveK

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld.bfd-plugin-link-order.diff
Type: text/x-c
Size: 5425 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20110129/f3c69bfa/attachment.bin>