From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13136 invoked by alias); 11 Sep 2014 00:32:59 -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 13116 invoked by uid 89); 11 Sep 2014 00:32:58 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-pa0-f52.google.com Received: from mail-pa0-f52.google.com (HELO mail-pa0-f52.google.com) (209.85.220.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 11 Sep 2014 00:32:57 +0000 Received: by mail-pa0-f52.google.com with SMTP id kq14so5745721pab.39 for ; Wed, 10 Sep 2014 17:32:55 -0700 (PDT) X-Received: by 10.66.161.41 with SMTP id xp9mr71557511pab.120.1410395575194; Wed, 10 Sep 2014 17:32:55 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-160-155-134.oycza5.sa.bigpond.net.au. [58.160.155.134]) by mx.google.com with ESMTPSA id d3sm8280002pbu.18.2014.09.10.17.32.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Sep 2014 17:32:54 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 7B6E1EA00A7; Thu, 11 Sep 2014 10:02:47 +0930 (CST) Date: Thu, 11 Sep 2014 00:32:00 -0000 From: Alan Modra To: Rafael =?iso-8859-1?Q?Esp=EDndola?= Cc: Cary Coutant , Ian Lance Taylor , Roland McGrath , "GNU C. Library" , Binutils Subject: Re: gold vs libc Message-ID: <20140911003247.GX17693@bubble.grove.modra.org> Mail-Followup-To: Rafael =?iso-8859-1?Q?Esp=EDndola?= , Cary Coutant , Ian Lance Taylor , Roland McGrath , "GNU C. Library" , Binutils 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00084.txt.bz2 On Wed, Sep 10, 2014 at 06:05:26PM -0400, Rafael Espíndola wrote: > > If the .eh_frame data in crt1.o really does need to come before > > __EH_FRAME_BEGIN__, another thing you could do is simply make it so > > gold treats it as non-optimizable. Adding a null relocation to the > > first word of the section should do it; inserting a zero-length entry > > anywhere but the end would do it (if that doesn't have adverse affects > > elsewhere). > > Since the problem comes from an optimizations that knows what > .eh_frame is, maybe it could learn that __EH_FRAME_BEGIN__ and > __EH_FRAME_END__ are special symbols marking the start and end of the > section? I'm inclined to think this is the best solution (and made a comment to that effect in pr17366 before reading this thread). I don't like the idea of making .eh_frame optimisation depend on --eh-frame-hdr. Providing a sorted list of FDEs is really separate to optimising those FDEs and CIEs. -- Alan Modra Australia Development Lab, IBM