From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21146 invoked by alias); 20 May 2005 14:54:54 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19486 invoked from network); 20 May 2005 14:53:54 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org with SMTP; 20 May 2005 14:53:54 -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 j4KErFeS014990; Fri, 20 May 2005 15:53:15 +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 j4KErLbC007887; Fri, 20 May 2005 15:53:21 +0100 Received: (from rearnsha@localhost) by pc960.cambridge.arm.com (8.12.8/8.12.8/Submit) id j4KErKUZ007885; Fri, 20 May 2005 15:53:20 +0100 X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha set sender to rearnsha@gcc.gnu.org using -f Subject: Re: RFC: Available registers as a target property From: Richard Earnshaw To: Daniel Jacobowitz Cc: gdb@sourceware.org In-Reply-To: <20050519010013.GA27885@nevyn.them.org> References: <20050506162029.GA30792@nevyn.them.org> <20050517193228.GB7337@nevyn.them.org> <1116408515.15608.40.camel@pc960.cambridge.arm.com> <20050519010013.GA27885@nevyn.them.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1116600800.18929.61.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 Date: Fri, 20 May 2005 14:54:00 -0000 X-SW-Source: 2005-05/txt/msg00220.txt.bz2 On Thu, 2005-05-19 at 02:00, Daniel Jacobowitz wrote: > On Wed, May 18, 2005 at 10:28:35AM +0100, Richard Earnshaw wrote: > > On Tue, 2005-05-17 at 20:32, Daniel Jacobowitz wrote: > > > > > /* If this flag is set, GDB should save and restore this register > > > around calls to an inferior function. */ > > > int save_restore; > > > > Why would the target care about this? It seems to be more a property of > > an ABI than the target. > > > > In the (IMO) unlikely case that we really want to keep this, I think it > > should have a 'not-my-responsibility-to-decide' setting. > > This isn't the conventional callee-saved vs. caller-saved decision. GDB > needs to handle bogus functions so it should save/restore all "normal" > registers, but there may be some registers in a system for which this > behavior is inappropriate. Perhaps there's a better name for this if I > invert the meaning... For instance, a debugger should probably not muck > with cp15 registers across a function call, even if they're not marked > readonly, to allow the user to modify them explicitly. > > I'm trying to express the concept of save_reggroup/restore_reggroup for > target specified registers. Have you got another idea of how to do it? > Maybe it's not necessary after all? Ah! Light dawns. Hmm, I've not thought this through in detail. Perhaps we should define access/protection classes that a register belongs to. Something along the lines of User - normal user-space registers Control - accessible by users, but generally stateful or volatile System - protected to system mode access only Sys-ctrl - Accessible by system, but generally stateful A parallel attribute might describe whether or not a register can be written, or whether it is purely for information. Examples (for ARM) for each of the above classess would be user - r0-r15 Control - VFP FPSCR System - r8_fiq, etc Sys-ctrl - cp15 This might be overkill for much of GDB's needs, but in some cases it might still not be enough. For example, the CPSR has some bits which are User, and some that are User/read-only, but system/read-write. R.