From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11546 invoked by alias); 31 Mar 2014 21:40:29 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 11524 invoked by uid 89); 31 Mar 2014 21:40:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: topped-with-meat.com Received: from toast.topped-with-meat.com (HELO topped-with-meat.com) (204.197.218.159) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 31 Mar 2014 21:40:27 +0000 Received: by topped-with-meat.com (Postfix, from userid 5281) id E61517447E; Mon, 31 Mar 2014 14:40:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Ian Lance Taylor Cc: Alan Modra , "GNU C. Library" , Binutils Subject: Re: gold vs libc In-Reply-To: Ian Lance Taylor's message of Monday, 31 March 2014 13:53:44 -0700 References: <20140330042516.1A88E74481@topped-with-meat.com> <20140330045552.GX18201@bubble.grove.modra.org> <20140330050615.7DC5774481@topped-with-meat.com> <20140331200446.A09B074430@topped-with-meat.com> Message-Id: <20140331214025.E61517447E@topped-with-meat.com> Date: Mon, 31 Mar 2014 21:40:00 -0000 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Rt9WckWK c=1 sm=1 tr=0 a=WkljmVdYkabdwxfqvArNOQ==:117 a=14OXPxybAAAA:8 a=Z6MIti7PxpgA:10 a=kj9zAlcOel0A:10 a=hOe2yjtxAAAA:8 a=EL95NHWQphQnKov-GncA:9 a=CjuIK1q_8ugA:10 X-SW-Source: 2014-03/txt/msg00325.txt.bz2 > On Mon, Mar 31, 2014 at 1:04 PM, Roland McGrath wrote: > > > > When an input file contains a symbol pointing to a location in an > > input section, the output file should define that symbol so it points > > to the part of the output section that corresponds to the origin input > > location. When the symbol points to input contents of at least one > > byte, what this means is pretty incontrovertibly clear. In this case, > > it points to an empty input section. But I claim that it's adequately > > clear what it should mean in this case too. > > It's really not. When the eh_frame section is being optimized, there > is no longer any correspondence between symbols defined in the input > sections and data defined in the output section. I understand that's what's going on underneath. But the user didn't ask you to fiddle with his .eh_frame contents. He did ask you to place some symbols in his .eh_frame section. If .eh_frame optimization is not transparent, then it's broken. IMHO it would be acceptable to simply disable .eh_frame optimization when there are any symbols in input .eh_frame sections that will survive to affect the output of anything except the .eh_frame output section's contents. (That tortured wording is to distinguish __EH_FRAME_BEGIN__, whose value is used by relocs in other sections like .text, from the various .L* symbols used within individual input sections that are only used in arithmetic producing values inside the section.) What's not acceptable is breaking the core semantics of linking that would apply if nobody had ever thought of .eh_frame optimization. > The current code has a simple algorithm that usually produces the > result we want: we simply copy .eh_frame sections until we find one we > can optimize. Perhaps we could change to a different algorithm: put > all unoptimized .eh_frame sections first, then all optimized .eh_frame > sections. In the concrete scenario, that would violate the abstract principles I described but would deliver an even better practical result. The empty .eh_frame section (and its __EH_FRAME_BEGIN__ symbol) from crtbeginT.o count as "unoptimized", while the .eh_frame content from crt1.o could count as "optimized". So it would place the emptiness and __EH_FRAME_BEGIN__ first, and everything else (including crt1.o's contributions) after, even though crt1.o appears before crtbeginT.o in the link. I think either this or disabling the optimization entirely are acceptable resolutions to the bug. Thanks, Roland