From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9893 invoked by alias); 31 Mar 2014 20:04:51 -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 9871 invoked by uid 89); 31 Mar 2014 20:04:50 -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 20:04:48 +0000 Received: by topped-with-meat.com (Postfix, from userid 5281) id A09B074430; Mon, 31 Mar 2014 13:04:46 -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 12:03:31 -0700 References: <20140330042516.1A88E74481@topped-with-meat.com> <20140330045552.GX18201@bubble.grove.modra.org> <20140330050615.7DC5774481@topped-with-meat.com> Message-Id: <20140331200446.A09B074430@topped-with-meat.com> Date: Mon, 31 Mar 2014 20:04: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=9wmLdxnHAF_doCczgI8A:9 a=CjuIK1q_8ugA:10 X-SW-Source: 2014-03/txt/msg00319.txt.bz2 > I don't fully understand this, but it seems to me that gold's > behaviour is correct and GNU ld's behaviour is incorrect. GNU ld is > effectively discarding the exception frame information in crt1.o, and > gold is retaining it. That is neither true nor relevant. I did not lodge any complaint about what contents wind up in the .eh_frame output section. The problem is how it's treating a symbol defined in an input section. GNU ld produces an __EH_FRAME_BEGIN__ symbol that points to the place in the output .eh_frame section that corresponds to the order of input files' .eh_frame sections. This does indeed point past the crt1.o CFI, but that is correct given the input file order (crt1.o and its .eh_frame content before crtbeginT.o and its __EH_FRAME_BEGIN__ symbol). Gold produces an __EH_FRAME_BEGIN__ symbol that points to the end of the .eh_frame output section. The effect of this is that gold is "effectively discarding" the entirety of the CFI. There is no logic of input sections and symbols and their order by which this result makes any kind of sense. The fact that it's CFI data is secondary IMHO. If the linker wants to optimize CFI data, then that's a fine thing. But its starting mandate has to be that it doesn't break the general rules of how link order and symbol values would come out if it were any other random rodata section rather than .eh_frame. > To put it another way: what principle should gold follow to get the > result you want? 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. Thanks, Roland