From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19430 invoked by alias); 7 May 2005 00:56:11 -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 18874 invoked from network); 7 May 2005 00:56:03 -0000 Received: from unknown (HELO rwcrmhc13.comcast.net) (204.127.198.39) by sourceware.org with SMTP; 7 May 2005 00:56:03 -0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (rwcrmhc13) with SMTP id <200505070056020150087blbe>; Sat, 7 May 2005 00:56:03 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 07 May 2005 00:56:00 -0000 Subject: Re: Available registers as a target property From: Paul Schlie To: Daniel Jacobowitz CC: Message-ID: In-Reply-To: <20050506232741.GA22741@nevyn.them.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00082.txt.bz2 > From: Daniel Jacobowitz >> 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. My sense is that the fundamental difference is where the information is described/contained, and how the choice of which description to use is conveyed to the GDB. Although I may misunderstand, it seems more consistent to enable GDB to select which of N register models to assume based upon the target's identification, than requiring the target to supply a detailed description of it's own register model; thereby not requiring any otherwise unnecessary complexity be added to the target's GDB server implementation? Where if a logical register/memory model description were formalized more centrally, (possibly within a more detailed BFD for the target architecture) then it may be more broadly leveraged my multiple tools, i.e. compiler, simulator, etc. in time, as opposed to being encapsulated in a GDB specific target implementation). Have I misunderstood your proposed approach?