From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24819 invoked by alias); 26 Sep 2003 09:33:27 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24751 invoked from network); 26 Sep 2003 09:33:20 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.54) by sources.redhat.com with SMTP; 26 Sep 2003 09:33:20 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id KAA14833; Fri, 26 Sep 2003 10:33:07 +0100 (BST) Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id h8Q9X7w16542; Fri, 26 Sep 2003 10:33:07 +0100 Message-Id: <200309260933.h8Q9X7w16542@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Andrew Cagney cc: Jerome Guitton , gdb-patches@sources.redhat.com, Richard.Earnshaw@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: [RFA/RFC] ARM : one-line prologue analysis In-reply-to: Your message of "Thu, 25 Sep 2003 17:32:30 EDT." <3F735EEE.3060306@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 2003 09:33:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-09/txt/msg00584.txt.bz2 > > for (reg = 0; reg < NUM_REGS; reg++) > > ! if (cache->saved_regs[reg].addr != -1) > > cache->saved_regs[reg].addr += cache->prev_sp; > > Would trad_frame_addr_p() be better? > > Andrew > > I think so. However, arm_scan_prologue (which is run just before this loop) abuses the .addr field and puts an offset into it. That offset can be (often is) negative at that point; the loop Jerome is fixing is the one where that offset is turned back into a real address. Fortunately, the stack will always be word aligned (your application is really broken if it isn't), and registers are always at least four bytes in size, so I don't think it's possible for -1 to ever get written in there by the code itself. So approved with Andrew's suggested change. R. PS Andrew, We seem to be horribly overloading and then exposing these special values in the trad_frame interface. Wouldn't it make more sense to add more routines to get and update the values, then we can hide the special meanings entirely (and maybe even change the way they are recorded if we need to). R.