From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 792 invoked by alias); 29 Apr 2010 13:17:22 -0000 Received: (qmail 781 invoked by uid 22791); 29 Apr 2010 13:17:22 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ksp.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.26.206) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Apr 2010 13:17:16 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 5C6B6F0BB6; Thu, 29 Apr 2010 15:17:14 +0200 (CEST) Date: Thu, 29 Apr 2010 14:08:00 -0000 From: Jan Hubicka To: Richard Guenther Cc: Dave Korn , Steven Bosscher , Toon Moene , gcc mailing list , Bingfeng Mei Subject: Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549] Message-ID: <20100429131714.GE22195@atrey.karlin.mff.cuni.cz> References: <4BD42686.1050604@moene.org> <4BD4C1DC.8000003@gmail.com> <4BD4F99C.9040508@gmail.com> <4BD906D5.1010408@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00941.txt.bz2 > Well, we'd then need to re-architect the symbol merging and > LTO unit read-in to properly honor linking semantics (drop > a LTO unit from an archive if it doesn't resolve any unresolved > symbols). I don't know how easy that will be, but it shouldn't > be impossible at least. We also should keep in mind that we really ought to be able to produce LTO .o files without actual assembly in, so either we should not tie this too much with linking process anyway or we need to output fake symbols into the LTO .o file when assembly is not done. (I guess one can just output empty variables and functions, but then .o will link without LTO and lead to wrong code). This is IMO quite important feature, we don't want to double compile times forever. Honza > > >  I'm sketching a plan where collect2 invokes 'ld' as if to do an ordinary > > non-LTO link, but passes it a flag like "--lto-assist" which causes it to > > output a list of just the archive members that it actually needs to complete > > the link, in response file "filename.a@offset" format.  ISTM that this is the > > simplest method to avoid recompiling entire archives (sort of building a > > linker into the compiler!), and I guess I should also make it check for an LTO > > marker (whether symbol or section) and only output those members that actually > > contain any LTO data. > > Yes - that would be basically a linker plugin without plugin support. > And I'd go even further and have LD provide a complete symbol > resolution set like we get from the gold linker-plugin. > > That wouldn't help for old or non-gnu LDs of course. > > >  Making lto1 understand archives seems logical at first, but I don't think > > it's much use without knowing which archive members we want in advance, and in > > that case the existing code that reads a single archive member by pretending > > it's an ordinary object file with a constant offset from the start of file > > marker already does all we need, or so it seems to me. > > I think we should try without lto1 understanding archives first > (or we are basically re-implementing a linker in lto1). > > Richard. > > >    cheers, > >      DaveK > > > >