From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18232 invoked by alias); 6 May 2005 23:27:46 -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 18053 invoked from network); 6 May 2005 23:27:41 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 6 May 2005 23:27:41 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DUCEP-0005v6-4F; Fri, 06 May 2005 19:27:41 -0400 Date: Fri, 06 May 2005 23:27:00 -0000 From: Daniel Jacobowitz To: Paul Schlie Cc: gdb@sourceware.org Subject: Re: Available registers as a target property Message-ID: <20050506232741.GA22741@nevyn.them.org> Mail-Followup-To: Paul Schlie , gdb@sourceware.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00081.txt.bz2 On Fri, May 06, 2005 at 06:46:38PM -0400, Paul Schlie wrote: > > Daniel Jacobowitz wrote: > > ... > > Today, the contents of the register cache and the layout of GDB's regnum > > space are determined by the gdbarch. There are several hooks for this, > > primarily these three: > > > > num_regs > > register_name > > register_type > > > > The gdbarch determines what raw registers are available. But this isn't a > > perfect match with what raw registers are _really_ available, because the > > gdbarch only has the clues we use to select a gdbarch available: things like > > byte order and BFD machine number. At best, those tell us what registers > > the binary we're debugging requires. The runtime set of registers we can > > see are a property of the target, not of the gdbarch. > > ... > > Might it be more appropriate to enable gdbarch to be extended to enable the > more specific description of a particular target component and mode; as > opposed to pushing the requirement of a target to provide detailed register > etc. information about itself when all that should be necessary should be > for it to more specifically identify itself and present mode if any, thereby > enabling a correspondingly more precise gdbarch description to be selected > as the basis of it's logically visible model? Do you have a concrete suggestion? This sounds not fundamentally different from what I am doing. -- Daniel Jacobowitz CodeSourcery, LLC