From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15920 invoked by alias); 7 Apr 2002 21:12:15 -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 15913 invoked from network); 7 Apr 2002 21:12:14 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 7 Apr 2002 21:12:14 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16uJxQ-0007zA-00 for ; Sun, 07 Apr 2002 17:12:16 -0400 Date: Sun, 07 Apr 2002 14:12:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [patch] Add PS_REGNUM. Message-ID: <20020407171216.A30655@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <3CAF59CA.1060304@cygnus.com> <20020407143417.A26612@nevyn.them.org> <3CB095CA.6090405@cygnus.com> <20020407165937.A30127@nevyn.them.org> <3CB0B559.3000306@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CB0B559.3000306@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00265.txt.bz2 On Sun, Apr 07, 2002 at 05:08:41PM -0400, Andrew Cagney wrote: > >I think it is the other way round. PS_REGNUM is the only one being used > >>correctly - when >=0, std-regs.c (new file) maps $ps onto a > >>hardware/pseudo register. Cf the GDB manual. > >> > >>On the other hand FP_REGNUM, PC_REGNUM and SP_REGNUM that are being used > >>``incorrectly''(1). They have no meaning outside of std-regs.c yet are > >>used throughout GDB. > > > > > >So what you're saying is that you added PS_REGNUM so that it could be > >used as a standard $ps register name, not for the rest of GDB, right? > > Yes. And that is how FP_REGNUM et.al. should be used .... Completely agree. > >I don't really see the point; anyone who wants to look at the processor > >status register presumably knows what some of the bits in it mean, > >which is entirely architecture dependant. But caveat implementor :) > > Who am I to argue with the documentation :-) Didn't know it was there, but now I see it. So true... :) -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer