From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31514 invoked by alias); 29 Jan 2011 01:45:21 -0000 Received: (qmail 31503 invoked by uid 22791); 29 Jan 2011 01:45:20 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 29 Jan 2011 01:45:15 +0000 Received: by vws10 with SMTP id 10so1308300vws.0 for ; Fri, 28 Jan 2011 17:45:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.177.65 with SMTP id bh1mr756476vcb.207.1296265513982; Fri, 28 Jan 2011 17:45:13 -0800 (PST) Received: by 10.220.184.2 with HTTP; Fri, 28 Jan 2011 17:45:13 -0800 (PST) In-Reply-To: <4D437207.4040903@gmail.com> References: <4D437207.4040903@gmail.com> Date: Sat, 29 Jan 2011 01:45:00 -0000 Message-ID: Subject: Re: [PATCH,trunk+2.21.1] Fix link order problem with LD plugin API. From: "H.J. Lu" To: Dave Korn Cc: "binutils@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-01/txt/msg00382.txt.bz2 On Fri, Jan 28, 2011 at 5:48 PM, Dave Korn wro= te: > > =A0 =A0Hi list, > > =A0This patch updates the existing plugin API in LD to correct the effect= ive > link order of the files added by the plugin. =A0(It does not deal with th= e need > for pass-throughs; that is a separate and orthogonal issue that I will ta= ckle > in a subsequent patch. =A0I hope that the combination of these two fixes = should > address all the same issues HJ's two-stage linking approach was designed = to fix.) > > =A0At the moment added files and libraries are simply concatenated onto t= he end > of the statement list. =A0This is more-or-less the same as adding them on= to the > end of the command-line; this means that their contributions get merged i= nto > sections after all the non-IR files, including in particular crtend.o. = =A0That's > pretty serious when it results in something like this: > >> .eh_frame =A0 =A0 =A0 0x00404000 =A0 =A0 =A00x200 >> =A0*(.eh_frame) >> =A0.eh_frame =A0 =A0 =A00x00404000 =A0 =A0 =A0 0x58 /gnu/gcc/obj-clean-r= 169274/gcc/testsuite/g++/../../crtbegin.o >> =A0.eh_frame =A0 =A0 =A00x00404058 =A0 =A0 =A0 0x5c /gnu/gcc/obj-clean-r= 169274/gcc/testsuite/g++/../../crtend.o >> =A0.eh_frame =A0 =A0 =A00x004040b4 =A0 =A0 =A0 0x68 /win/c/DOCUME~1/ADMI= NI~1/LOCALS~1/Temp/ccF5bqWv.lto.o > > because it breaks EH! > > =A0The 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. > > =A0In LD, there's nothing to "defer", as layout hasn't begun yet. =A0All = we need > to do is add the replacement files into the middle of the existing statem= ent > list, immediately after the first claimed IR file. =A0Complicated only sl= ightly > by the fact that there are in fact three separate singly-linked chains th= rough > the list of statements, that's what this patch does, and it results in the > correct result: > >> .eh_frame =A0 =A0 =A0 0x00404000 =A0 =A0 =A00x200 >> =A0*(.eh_frame) >> =A0.eh_frame =A0 =A0 =A00x00404000 =A0 =A0 =A0 0x58 /gnu/gcc/obj-clean-r= 169274/gcc/testsuite/g++/../../crtbegin.o >> =A0.eh_frame =A0 =A0 =A00x00404058 =A0 =A0 =A0 0x68 /win/c/DOCUME~1/ADMI= NI~1/LOCALS~1/Temp/ccfuGGNR.lto.o >> =A0.eh_frame =A0 =A0 =A00x004040c0 =A0 =A0 =A0 0x5c /gnu/gcc/obj-clean-r= 169274/gcc/testsuite/g++/../../crtend.o > > ld/ChangeLog: > > 2011-01-29 =A0Dave Korn =A0 > > =A0 =A0 =A0 =A0* ldlang.c (lang_process): After adding and opening new in= put files > =A0 =A0 =A0 =A0passed from plugin, splice them into correct place in stat= ement list > =A0 =A0 =A0 =A0chains to preserve critical link order. > =A0 =A0 =A0 =A0(lang_list_insert_after): New helper function. > =A0 =A0 =A0 =A0(lang_list_remove_tail): Likewise. > > =A0Built and tested on i686-pc-cygwin. =A0I'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. --=20 H.J.