From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4595 invoked by alias); 29 Apr 2010 11:39:46 -0000 Received: (qmail 4552 invoked by uid 48); 29 Apr 2010 11:39:34 -0000 Date: Thu, 29 Apr 2010 11:39:00 -0000 Message-ID: <20100429113934.4547.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/43729] Mach-O LTO support needed for darwin In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "steven at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg03111.txt.bz2 ------- Comment #17 from steven at gcc dot gnu dot org 2010-04-29 11:39 ------- I've played a bit with modified .s files by hand, and as/ld work if the LTO sections follow the other sections. The normal order of output with -flto looks like this in the .s file: LTO sections (the __GNU_LTO stuff) .text / .data / etc. (all non-LTO sections) LTO __section_names section With this order I get the linker error. I do *not* get the linker error if I re-order the .s file by hand to look like this: .text / .data / etc. (all non-LTO sections) LTO sections (the __GNU_LTO stuff) LTO __section_names section With this order, the .s file looks identical with and without -flto, except for the extra LTO sections after the non-LTO stuff of course. And with this order, the linker doesn't give an error. I don't understand this at all. It is almost as if the compiler somehow writes an address relative to start-of-file, but the compiler doesn't know about addresses (it can write labels and such, but not count bytes from start-of-file). Anyway, I did some research with Google and we are not the first to encounter this problem. Apparently it doesn't happen in 32-bits mode, so I'll implement that now and try that. The important conclusion for me, is that the LTO patch is OK and the bug is somewhere else :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729