From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22577 invoked by alias); 29 Mar 2015 03:49:09 -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 22561 invoked by uid 89); 29 Mar 2015 03:49:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-pd0-f174.google.com Received: from mail-pd0-f174.google.com (HELO mail-pd0-f174.google.com) (209.85.192.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 29 Mar 2015 03:49:05 +0000 Received: by pddn5 with SMTP id n5so22477447pdd.2 for ; Sat, 28 Mar 2015 20:49:04 -0700 (PDT) X-Received: by 10.70.35.2 with SMTP id d2mr47747921pdj.51.1427600944172; Sat, 28 Mar 2015 20:49:04 -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 j4sm6391945pdk.76.2015.03.28.20.49.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Mar 2015 20:49:03 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 30807EA0174; Sun, 29 Mar 2015 14:18:58 +1030 (ACDT) Date: Sun, 29 Mar 2015 03:49:00 -0000 From: Alan Modra To: "H.J. Lu" Cc: Binutils Subject: Re: [PATCH] Reduce file size for PT_GNU_RELRO segment Message-ID: <20150329034858.GH26234@bubble.grove.modra.org> Mail-Followup-To: "H.J. Lu" , Binutils References: <20150319130244.GA22592@intel.com> <20150326022246.GU26234@bubble.grove.modra.org> <20150328041540.GE26234@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00429.txt.bz2 On Sat, Mar 28, 2015 at 03:46:49PM -0700, H.J. Lu wrote: > On Sat, Mar 28, 2015 at 11:30 AM, H.J. Lu wrote: > > On Fri, Mar 27, 2015 at 9:15 PM, Alan Modra wrote: > >> On Fri, Mar 27, 2015 at 01:00:20PM -0700, H.J. Lu wrote: > >>> On Wed, Mar 25, 2015 at 7:22 PM, Alan Modra wrote: > >>> > Isn't this just re-inventing the commonpage adjustment done for > >>> > DATA_SEGMENT_ALIGN? Why didn't the existing code in ldexp.c work for > >>> > you? > >>> > >>> segment. In order to properly align PT_GNU_RELRO segmnet, we pad the first > >>> section of PT_GNU_RELRO segment by > >> > >> Adjusting the start of the first section of the PT_GNU_RELRO segment > >> is exactly what DATA_SEGMENT_ALIGN is supposed to do. You are > >> patching the wrong place. Any adjustment to the start of the relro > >> segment belongs in ldexp.c code evaluating DATA_SEGMENT_ALIGN. > > > > Since output_section_statement isn't passed to ldexp.c, I don't see how > > DATA_SEGMENT_ALIGN in ldexp.c can check the section address and size. > > lang_size_sections aligns expld.dataseg.base: You're correct. I thought I knew this code well enough to review your patch without looking at the existing code. Obviously not. Howver, I'm glad you also had to look at the entirety of the relro code as that should make you realize that the patch you posted isn't very elegant. For instance, there is no need for output_prev_load_sec_find since the end of the previous section is available in expld.dataseg.min_base. Also, the bulk of the patch still belongs with the other relro code handling DATA_SEGMENT_ALIGN (not in ldexp.c as I wrongly claimed before, but in lang_size_sections). I think it important that we keep the relro base alignment code all in one place. -- Alan Modra Australia Development Lab, IBM