From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26574 invoked by alias); 12 Mar 2014 22:52:50 -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 26558 invoked by uid 89); 12 Mar 2014 22:52:49 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f43.google.com Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com) (209.85.220.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 12 Mar 2014 22:52:48 +0000 Received: by mail-pa0-f43.google.com with SMTP id bj1so198326pad.2 for ; Wed, 12 Mar 2014 15:52:47 -0700 (PDT) X-Received: by 10.68.202.8 with SMTP id ke8mr197575pbc.86.1394664767169; Wed, 12 Mar 2014 15:52:47 -0700 (PDT) Received: from bubble.grove.modra.org ([101.166.26.37]) by mx.google.com with ESMTPSA id ug9sm626666pbc.11.2014.03.12.15.52.45 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Mar 2014 15:52:46 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 9ADFAEA00D2; Thu, 13 Mar 2014 09:22:42 +1030 (CST) Date: Wed, 12 Mar 2014 22:52:00 -0000 From: Alan Modra To: Roland McGrath Cc: "binutils@sourceware.org" Subject: Re: [RFC PATCH] Avoid emitting TEXTREL marker for R_ARM_NONE relocs. Message-ID: <20140312225242.GX26922@bubble.grove.modra.org> Mail-Followup-To: Roland McGrath , "binutils@sourceware.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00119.txt.bz2 On Wed, Mar 12, 2014 at 10:17:32AM -0700, Roland McGrath wrote: > I have a dim memory of someone explaining that emitting R_ARM_NONE dynamic > relocs was intractable to avoid in some cases. But I don't understand what > situations cause that to happen. Nor could I figure out today where in the > code it actually happens. One case that springs to mind is .eh_frame editing, which happens after dynamic relocations have been allocated. If you require dynamic relocations in .eh_frame CIEs (say due to using absolute encoding for some field) and CIEs are merged, then you can end up needing fewer dynamic relocations than allocated. Do you know where the R_ARM_NONE dynamic reloc came from? Tip: -z nocombreloc helps in answering that question. > @@ -13766,8 +13766,13 @@ elf32_arm_size_dynamic_sections (bfd * > output_bfd ATTRIBUTE_UNUSED, > { > srel = elf_section_data (p->sec)->sreloc; > elf32_arm_allocate_dynrelocs (info, srel, p->count); > - if ((p->sec->output_section->flags & SEC_READONLY) != 0) > - info->flags |= DF_TEXTREL; > + /* It would appear that we could check for the output > + section being SEC_READONLY and set DF_TEXTREL here. > + But these relocs might be morphed into R_ARM_NONE > + later, making the test here false-positive. > + Instead, we'll just let the scan at the end of the > + function (using elf32_arm_readonly_dynrelocs) catch > + any that survive. */ No, this is wrong. The code you're touching here deals with relocations for local symbols, elf32_arm_readonly_dynrelocs scans global symbols. -- Alan Modra Australia Development Lab, IBM