From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5724 invoked by alias); 3 Dec 2010 19:17:02 -0000 Received: (qmail 5707 invoked by uid 22791); 3 Dec 2010 19:17:01 -0000 X-SWARE-Spam-Status: No, hits=-2.2 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-qy0-f169.google.com (HELO mail-qy0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 03 Dec 2010 19:16:56 +0000 Received: by qyk7 with SMTP id 7so1170418qyk.0 for ; Fri, 03 Dec 2010 11:16:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.184.207 with SMTP id cl15mr1697750qcb.190.1291403814786; Fri, 03 Dec 2010 11:16:54 -0800 (PST) Received: by 10.220.61.13 with HTTP; Fri, 3 Dec 2010 11:16:54 -0800 (PST) In-Reply-To: References: Date: Fri, 03 Dec 2010 19:17:00 -0000 Message-ID: Subject: Re: Update LTO plugin interface From: "H.J. Lu" To: Cary Coutant Cc: Ian Lance Taylor , GCC Development , Binutils 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: 2010-12/txt/msg00161.txt.bz2 On Fri, Dec 3, 2010 at 11:10 AM, Cary Coutant wrote: >>>> Another way to do this would be to put a marker in the command line >>>> that identifies where those libraries begin, and the linker could just >>>> go back and rescan those libraries if needed, before the final layout >>>> of the endcaps. >>> >>> I like that idea in general, but the difficulty is knowing where to put >>> the marker. =A0E.g., the user is going to specify -lm, and we are going= to >>> need to rescan it. =A0If the user writes -lm -lmylib1 -lmylib2 we want = to >>> rescan -lm but we don't really need to rescan mylib1 and mylib2. >> >> All those complexities make 2 stage linking more attractive. =A0I >> think I can implement it in GNU linker with the current plugin API. >> >> Linker just needs to remember the command line options, including >> >> --start-group/--end-group >> -as-needed/--no-as-needed >> --copy-dt-needed-entries/--no-copy-dt-needed-entries >> >> in stage 1. >> >> In stage 2, it will place LTO trans files before the first IR file >> claimed by plugin and process the command line options. >> >> --whole-archive may need some special handling. =A0Archives >> after --whole-archive will be ignored in stage 2. > > It seems to me that we just need to add a few more libraries as > pass-through libraries, being careful to add a pass-through option > only for libraries that are already on the command line. How does that > add up to "all those complexities"? > > With what you've written here, you've just added to the complexity of > your proposed solution, which makes it a much bigger change -- > especially since what you're proposing will require changes in both > linkers. Adding pass-through options is a gcc driver change only. > I will implement 2 stage linking in GNU linker with the current plugin API. The change shouldn't be too big. pass-through isn't needed. If we keep it in GCC driver, my linker will simply ignore it. One benefit is everything will just work, with or without LTO. --=20 H.J.