From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31268 invoked by alias); 13 Mar 2011 19:07:32 -0000 Received: (qmail 31259 invoked by uid 22791); 13 Mar 2011 19:07:31 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 13 Mar 2011 19:07:25 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 21ABE9AC8E2; Sun, 13 Mar 2011 20:07:23 +0100 (CET) Date: Sun, 13 Mar 2011 19:07:00 -0000 From: Jan Hubicka To: Chris Lattner Cc: Jack Howarth , Jan Hubicka , gcc@gcc.gnu.org Subject: Re: darwin LTO broken under Xcode 3.2.6/4.0 Message-ID: <20110313190723.GA10895@kam.mff.cuni.cz> References: <20110313041719.GA17752@bromo.med.uc.edu> <20110313113926.GP12469@atrey.karlin.mff.cuni.cz> <20110313153841.GA11318@bromo.med.uc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2011-03/txt/msg00154.txt.bz2 > > On Mar 13, 2011, at 8:38 AM, Jack Howarth wrote: > > > On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote: > >>> With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made to > >>> the darwin assembler which effectively breaks LTO support for darwin. The design > >>> of LTO on darwin was based on the fact that mach-o object files tolerated additional > >>> sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the assembler > >>> appears to be strictly counting sections and objecting when these exceed 255. This > >>> breaks huge sections of the lto testsuite and prevents larger projects like xplor-nih > >>> to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple reverts this > >>> change, our only recourse would be to resort to an elf object container for the lto > >>> sections within the mach-o files (introducing an undesired dependency on libelf for > >>> FSF gcc on darwin). My understanding was that the lto design did not allow the number > >>> of sections required in the lto files to be reduced. > >> > >> If the problem is not fixed, we could always pack all the LTO sections into one section containing > >> our own subsections. > >> > >> Honza > > > > Jan, > > If this could be done without resorting to other container types (like elf), it might be > > the wisest approach for the long run. I've read through the mach-o documentation and it > > seems rather vague on the section limits. Even if Apple fixes Xcode (which likley won't > > happen for 6-9 months at best), we always we have to worry that they will break this > > 'feature' somewhere else in their tool chain. Better to follow the strictest possible reading > > of mach-o object format to protect ourselves from overzealous Apple interns. > > Yes, I agree that this is a better solution. This error was put into the linker to detect some overflow conditions for part of the code that expected the section number to only be a byte. It is likely that "things worked" only out of luck before. Interesting, so there is no -ffunction-section type tricks at darwin? Pickling everything into single section seems indeed like easiest approach here. The question is who will volunteer to implement it ;) Honza > > -Chris