From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9413 invoked by alias); 11 Sep 2014 18:33:33 -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 9391 invoked by uid 89); 11 Sep 2014 18:33:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 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-GCM-SHA384 encrypted) ESMTPS; Thu, 11 Sep 2014 18:33:31 +0000 Received: by topped-with-meat.com (Postfix, from userid 5281) id 88ABE2C3978; Thu, 11 Sep 2014 11:33:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Cary Coutant Cc: Ian Lance Taylor , Alan Modra , "GNU C. Library" , Binutils , =?UTF-8?Q?Rafael_=C3=81vila_de_Esp=C3=ADndola?= Subject: Re: gold vs libc In-Reply-To: Cary Coutant's message of Thursday, 11 September 2014 09:00:06 -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> <20140331214025.E61517447E@topped-with-meat.com> <20140910225238.0B6362C39CF@topped-with-meat.com> Message-Id: <20140911183329.88ABE2C3978@topped-with-meat.com> Date: Thu, 11 Sep 2014 18:33:00 -0000 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=SvUDtp+0 c=1 sm=1 tr=0 a=WkljmVdYkabdwxfqvArNOQ==:117 a=14OXPxybAAAA:8 a=8rIOUStOCdkA:10 a=Z6MIti7PxpgA:10 a=kj9zAlcOel0A:10 a=hOe2yjtxAAAA:8 a=0Px_mVOAgapKcT7SrPgA:9 a=CjuIK1q_8ugA:10 X-SW-Source: 2014-09/txt/msg00092.txt.bz2 > I don't like the idea of checking for specific symbol name to give > special treatment to a section. I wouldn't mind simply making > __EH_FRAME_BEGIN__ and __EH_FRAME_END__ linker-defined symbols that > would override any definitions found in the object files. The notion as I read it was that when the linker decides to rewrite .eh_frame data, it defines these symbols accordingly. > I could also special case by filename -- check is_in_system_directory(), > and if true, check the filename to see if it contains "begin" or "end". The horror, the horror. > BTW, my copy of crtend.o doesn't define __EH_FRAME_END__. It does > define __FRAME_END, but it's a local symbol. Having the linker provide > __EH_FRAME_END__ would be consistent, and shouldn't break anything. > With this proposal, __FRAME_END would get the right value anyway. > (Until, that is, someone comes along with another crtend-like file and > decides it needs CFI as well!) Nothing needs or uses an end symbol (there's an in-band terminator) and there is no canonical name for one, so I don't think you should define one. In fact, __EH_FRAME_BEGIN__ is not a global symbol either. It's not actually a canonical name. It's just used inside crtbeginT.o, which defines it in .eh_frame and uses it in a reloc in .text. There is no such symbol around at all by link time that matters. There is just a reloc using the STT_SECTION symbol for .eh_frame. (At least that's what I see on by x86_64 system. I've never been very clear on when the assembler uses a specific local symbol in a reloc vs reducing it to a section symbol, and I suspect it varies across machines.) So the symbol idea doesn't fly. You could instead special-case a reloc against .eh_frame+0 in an input file with an empty .eh_frame. Off hand, I think this might well be the only reloc against a .eh_frame input section you will ever see. So perhaps really the right thing to do is verify that there is at most one reloc against .eh_frame anywhere (and perhaps that it is against an empty input .eh_frame section) and treat it specially if so--but either error or disable .eh_frame optimization if there are any more relocs into .eh_frame sections. I can't really imagine any situation with a reloc pointing into .eh_frame whose intended semantics wouldn't be probably broken by .eh_frame optimization. Thanks, Roland