From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31508 invoked by alias); 8 Oct 2004 19:22:47 -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 31498 invoked from network); 8 Oct 2004 19:22:45 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Oct 2004 19:22:45 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i98JMjFN015402 for ; Fri, 8 Oct 2004 15:22:45 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i98JMir14689; Fri, 8 Oct 2004 15:22:44 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C76BB28D2; Fri, 8 Oct 2004 15:22:19 -0400 (EDT) Message-ID: <4166E8EB.2070207@gnu.org> Date: Fri, 08 Oct 2004 22:10:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Dave Korn Cc: "'Eli Zaretskii'" , gdb@sources.redhat.com Subject: Re: Discussion: Formalizing the deprecation process in GDB References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00267.txt.bz2 > Also, 9.5 and 9.6 are both prefixed with disclaimers; 9.5 says "This > section is pretty much obsolete. The functionality described here has > largely been replaced by pseudo-registers and the mechanisms described [... > in 9.6 ...] " and refers the reader to 9.6, which says "The way GDB > manipulates registers is undergoing significant change. Many of the macros > and functions refered to in this section are likely to be subject to further > revision.". The combined effect of these two sections is to leave the > reader (well, this one, at any rate) with no idea how you're supposed to > manipulate registers (or indeed, what a pseudo-register even is, since the > term is not used nor defined anywhere else in the documentation). And I > didn't find that browsing the comments in regcache.h makes up for that. Like the below? http://sources.redhat.com/ml/gdb/2002-07/msg00202.html @node Registers @chapter Registers @section Register Spaces @value{GDBN} internally has two register spaces: @table @emph @item cooked @itemize @bullet @item manipulated by core @value{GDBN} @item correspond to user level, or abi registers @end itemize @item raw @itemize @bullet @item manipulated by target backends @item correspond to physical registers @end itemize @end table @subsection Raw Registers The raw register space, containing @code{NUM_REGS} @c index NUM_REGS raw registers, abstracts the instruction set architectures physical register set. @value{GDBN}'s register cache contains raw registers. Each raw register is mapped, one-to-one, onto a corresponding physical register. For instance: @itemize @bullet @item For 64 bit architecture that has 32 general purpose registers, the register cache, and the raw register space would include space for those 32 registers. @item For an architectures that has register banks, the register cache, and raw register space would contain space for registers from all banks. The one-to-one relationship between the raw registers and the architecture's physical registers being preserved. @item For a 64 bit architecture that is running in 32 bit mode, the register cache and raw register space would contain the 64 bit hardware registers. The raw register space would not include cut down 32 bit registers. @item For an architecture that determines the program-counter by examining the value of severaal hardware registers, the register cache and raw register space will contain the separate hardware values. The raw register space would not include the program-counter. @item For an architecture that has memory mapped registers, those registers are not be part of the register cache or raw register space (there is no corresponding hardware register). @end itemize @emph{Maintainer note: Old architectures, since they didn't know better, broke all of the above rules, sigh!} The raw registers are not necessarily directly visible to the user. @emph{Maintainer note: There should be be a @samp{maint info registers} command so that the raw register cache is visible.} @section Cooked Registers The core of @value{GDBN} manipulates registers in the cooked register space. Any external or user visible register is mapped onto the cooked register space, in particular: @itemize @bullet @item registers refered to by debug information @item user visible registers (specified by name) @item mode dependant registers (e.g., a 64 bit architecture in 32 bit mode may need to manipulate the 32 bits of 64 bit registers) @item memory mapped registers space. @item state dependant registers (e.g., bank registers) @end itemize Architecture methods then map the @code{NUM_REGS + NUM_PSEUDO_REGS} cooked registers onto raw registers or memory. While arbitrary mappings are possible, the first @code{NUM_REGS} registers should be be mapped direct to the raw registers. The remaining @code{NUM_PSEUDO_REGS then having more arbitrary mappings. That is: @smallexample cooked: [0..NUM_REGS) [..NUM_REGS+NUM_PSEUDO_REGS) | / | | / | | / | | / | raw: RAW REGISTERS MEMORY @end smallexample @section The Register Cache @value{GDBN} stores the target register state in a register cache (@code{struct regcache}). The register cache has three separate interfaces: @itemize @bullet @item cooked @item raw @item target @end itemize Core @value{GDBN} manipulates the register cache using the cooked interfaces: @deftypefun void regcache_cooked_read (struct regcache *@var{regcache}, int @var{regnum}, void *@var{buf}) Read a cooked register value from the register cache (or memory). @end deftypefun @deftypefun void regcache_cooked_write (struct regcache *@var{regcache}, int @var{regnum}, const void *@var{buf}) Write a cooked register value to the register cache (or memory). @end deftypefun These methods then use corresponding architecture methods to map the cooked registers onto either raw registers or memory: @deftypefun void gdbarch_cooked_register_read (struct gdbarch *@var{gdbarch}, struct regcache *@var{regcache}, int @var{regnum}, void *@var{buf}) Read the specified @var{regnum} register value from the @var{regcache} (or memory for memory mapped registers). @end deftypefun @deftypefun void gdbarch_cooked_register_write (struct gdbarch *@var{gdbarch}, struct regcache *@var{regcache}, int @var{regnum}, const void *@var{buf}) Write the specified @var{regnum} register value into the @var{regcache} (or memory for memory mapped registers). @end deftypefun The raw register values being manipulated using: @deftypefun void regcache_raw_read (struct regcache *@var{regcache}, int @var{regnum}, void *@var{buf}) Read a cooked register value from the register cache (or memory). @end deftypefun @deftypefun void regcache_raw_write (struct regcache *@var{regcache}, int @var{regnum}, const void *@var{buf}) Write a raw register value to the register cache (or memory). @end deftypefun When a raw register read or write needs to go through to the target (the value isn't yet in the cache or a modification needs to be written to the target) the register cache state is then manipulated by the target using the methods: @deftypefun regcache_collect (struct regcache *@var{regcache}, int @var{regnum}, void *@var{buf}) @end deftypefun @deftypefun regcache_supply (struct regcache *@var{regcache}, int @var{regnum}, const void *@var{buf}) @end deftypefun