From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3071 invoked by alias); 5 Dec 2011 21:03:21 -0000 Received: (qmail 3059 invoked by uid 22791); 5 Dec 2011 21:03:20 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Dec 2011 21:03:06 +0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto Date: Mon, 05 Dec 2011 21:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2011-12/txt/msg00485.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 --- Comment #12 from Iain Sandoe 2011-12-05 21:01:09 UTC --- (In reply to comment #11) > I think that later versions of the vendor's tools make some of the ObjC > sections merge-able - so that's a possibility Unfortunately, not the _image_info sections. === So .. this is the problem.... We have n object files input to lto. Each object contains ObjC meta-data... including a single var in the _image_info section. Although these image_info vars will eventually be overlaid, they are not common-like - because they can be non-zero. (Darwin's) ld can merge them, because ld knows that the property of the _image_info section is that it holds a single instance of the L_OBJC_ImageInfo variable. So ld can check that these are compatible between objects, and merge/error as appropriate. but LTO will concatenate them - leading to two problems: (a) the section appears to be too big - complaint from later versions of ld and (b) they are no longer being error-checked and combined - which might have much more subtle implications. > - otherwise - Honza any suggestions? e.g. Is there any annotation or hook that we can use to emulate this behavior? (I don't think DECL_ONE_ONLY is quite right because it might be [legitimately] possible for the vars to have differing values - I need to check that carefully) I guess, ideally, the ObjC meta-data should be re-created after LTO has done its magic -- but that's def. not a stage 3 type job ... .. maybe move it to be a late (Post Optimization) pass? [ISTM, at a first consideration, there should be no need to optimize ObjC metadata under those circumstances, since it should only be created as required in response to the remaining (optimized) content]