From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15737 invoked by alias); 29 Mar 2005 15:23:09 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 15562 invoked from network); 29 Mar 2005 15:22:45 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org with SMTP; 29 Mar 2005 15:22:45 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id j2TFLs4G003723; Tue, 29 Mar 2005 16:21:54 +0100 (BST) Received: from pc960.cambridge.arm.com (localhost.localdomain [127.0.0.1]) by pc960.cambridge.arm.com (8.12.8/8.12.8) with ESMTP id j2TFM8IF012741; Tue, 29 Mar 2005 16:22:08 +0100 Received: (from rearnsha@localhost) by pc960.cambridge.arm.com (8.12.8/8.12.8/Submit) id j2TFM8k1012739; Tue, 29 Mar 2005 16:22:08 +0100 X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha set sender to rearnsha@gcc.gnu.org using -f Subject: Re: ARM: Fix DT_TEXTREL generation From: Richard Earnshaw To: Daniel Jacobowitz Cc: binutils@sources.redhat.com In-Reply-To: <20050325160121.GA16066@nevyn.them.org> References: <20050325160121.GA16066@nevyn.them.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: GNU Message-Id: <1112109728.12337.0.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 Date: Tue, 29 Mar 2005 16:21:00 -0000 X-SW-Source: 2005-03/txt/msg00862.txt.bz2 On Fri, 2005-03-25 at 16:01, Daniel Jacobowitz wrote: > I posted this patch a couple days ago, but at the bottom of a thread ... > tsk tsk. > > This patch prevents the incorrect generation of a DT_TEXTREL tag in ARM > shared libraries. The problem was that p->count was correctly updated, > but we would sometimes create new relocs_copied entries with a zero count; > and when checking for text relocations, we don't look at the count, just > whether the pointer is non-NULL. The cleanest fix is to avoid creating a > new relocs_copied structure if we aren't going to increment it. > > OK for HEAD? Any objection to fixing this on 2.16 also? This is OK for head. For the record, I'm happy for this to go into 2.16 too, but I'm not sure if that's my call. R.