From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39739 invoked by alias); 26 Nov 2015 00:54:41 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 39727 invoked by uid 89); 26 Nov 2015 00:54:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mga03.intel.com Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Nov 2015 00:54:39 +0000 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 25 Nov 2015 16:54:38 -0800 X-ExtLoop1: 1 Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.156]) by orsmga003.jf.intel.com with ESMTP; 25 Nov 2015 16:54:39 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id 4FCF1302AFE; Wed, 25 Nov 2015 16:54:38 -0800 (PST) Date: Thu, 26 Nov 2015 01:55:00 -0000 From: Andi Kleen To: Jan Hubicka Cc: gcc-patches@gcc.gnu.org, rguenther@suse.de, hongjiu.lu@intel.com, ccoutant@google.com, iant@google.com Subject: Re: [RFC] Getting LTO incremental linking work Message-ID: <20151126005438.GJ8438@tassilo.jf.intel.com> References: <20151125085912.GD58491@kam.mff.cuni.cz> <20151125235858.GI8438@tassilo.jf.intel.com> <20151126003828.GH20593@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151126003828.GH20593@kam.mff.cuni.cz> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2015-11/txt/msg03169.txt.bz2 > > In theory we could change the build system to avoid that case though, but > > it would need some changes. > > > > It would be better if that could be handled somehow. > > How does this work with your patchset? Ideally we should have way to claim > only portions of object files, but we don't have that. If we claim the file, > the symbols in real symbol table are not visible. It works with HJ's Linux binutils. It handles LTO and non LTO separately. > I suppose we could play a games here with slim LTO: claim the file, see if > there are any symbols defined in the non-LTO symbol table and if so, interpret > read the symbol table and tell linker about the symbols and at the very end > include the offending object file in the list of objects returned back to > linker. > > The linker then should take the symbols it wants. There would be some fun > involved, because the resolution info we get will consider the symbols > defined in that object file to be IR which would need to be compensated for. Yes something like that would be needed. -Andi -- ak@linux.intel.com -- Speaking for myself only