From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24385 invoked by alias); 29 Jan 2011 02:05:52 -0000 Received: (qmail 24296 invoked by uid 22791); 29 Jan 2011 02:05:50 -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 02:05:43 +0000 Received: by vws10 with SMTP id 10so1313372vws.0 for ; Fri, 28 Jan 2011 18:05:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.188.6 with SMTP id cy6mr759425vcb.242.1296266741864; Fri, 28 Jan 2011 18:05:41 -0800 (PST) Received: by 10.220.184.2 with HTTP; Fri, 28 Jan 2011 18:05:41 -0800 (PST) In-Reply-To: References: <4D437207.4040903@gmail.com> Date: Sat, 29 Jan 2011 02:05: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/msg00384.txt.bz2 On Fri, Jan 28, 2011 at 6:01 PM, H.J. Lu wrote: > On Fri, Jan 28, 2011 at 5:45 PM, H.J. Lu wrote: >> On Fri, Jan 28, 2011 at 5:48 PM, Dave Korn = wrote: >>> >>> =A0 =A0Hi list, >>> >>> =A0This patch updates the existing plugin API in LD to correct the effe= ctive >>> link order of the files added by the plugin. =A0(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. =A0I hope that the combination of these two fixe= s should >>> address all the same issues HJ's two-stage linking approach was designe= d to fix.) >>> >>> =A0At the moment added files and libraries are simply concatenated onto= the end >>> of the statement list. =A0This 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. = =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= -r169274/gcc/testsuite/g++/../../crtbegin.o >>>> =A0.eh_frame =A0 =A0 =A00x00404058 =A0 =A0 =A0 0x5c /gnu/gcc/obj-clean= -r169274/gcc/testsuite/g++/../../crtend.o >>>> =A0.eh_frame =A0 =A0 =A00x004040b4 =A0 =A0 =A0 0x68 /win/c/DOCUME~1/AD= MINI~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. =A0Al= l we need >>> to do is add the replacement files into the middle of the existing stat= ement >>> list, immediately after the first claimed IR file. =A0Complicated 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 =A0 =A0 =A0 0x00404000 =A0 =A0 =A00x200 >>>> =A0*(.eh_frame) >>>> =A0.eh_frame =A0 =A0 =A00x00404000 =A0 =A0 =A0 0x58 /gnu/gcc/obj-clean= -r169274/gcc/testsuite/g++/../../crtbegin.o >>>> =A0.eh_frame =A0 =A0 =A00x00404058 =A0 =A0 =A0 0x68 /win/c/DOCUME~1/AD= MINI~1/LOCALS~1/Temp/ccfuGGNR.lto.o >>>> =A0.eh_frame =A0 =A0 =A00x004040c0 =A0 =A0 =A0 0x5c /gnu/gcc/obj-clean= -r169274/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 = input files >>> =A0 =A0 =A0 =A0passed from plugin, splice them into correct place in st= atement 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. =A0They are tested >> if GCC supports LTO. =A0You should try your ld changes on those new >> LTO tests. =A0You can ignore those mixed IR failures. But other LTO tests >> should pass. =A0I can post a patch for LTO testcases if you want. >> > > Here is the new LTO tests. =A0The 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. --=20 H.J.