From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21277 invoked by alias); 7 May 2005 03:49:09 -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 21257 invoked from network); 7 May 2005 03:49:04 -0000 Received: from unknown (HELO rwcrmhc14.comcast.net) (216.148.227.89) by sourceware.org with SMTP; 7 May 2005 03:49:04 -0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (rwcrmhc14) with SMTP id <20050507034903014009f3mie>; Sat, 7 May 2005 03:49:03 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 07 May 2005 03:49:00 -0000 Subject: Re: Available registers as a target property From: Paul Schlie To: Daniel Jacobowitz CC: Message-ID: In-Reply-To: <20050507013640.GA26032@nevyn.them.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00084.txt.bz2 > From: Daniel Jacobowitz > On Fri, May 06, 2005 at 08:55:59PM -0400, Paul Schlie wrote: >> 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? > > The proposal supports both. This is the difference between > register/feature sets and individual registers. > > All hardware does not fit into nice models that GDB can know about. A > synthesized ARM core, for instance, can have arbitrary proprietary > coprocessors on it, designed by whoever synthesized the design. Or > even in ia32 land, the set of MSRs available varies wildly, and it is > not GDB's business to track that level of details about every > x86-compatible processor ever made. > > Maintaining a central registry of all register configurations is not > practical. Understood, but given that these semi-customizable synthesizable processors still need to have their configurations described to multiple tools, it still seems that adopting a more centralized specification scheme which enables their configuration descriptions to be more conveniently accessible by whatever tools may choose to leverage them seems like a good thing; as opposed to having creating discrete depositories/methods unique to each tool. Which is why potentially broadening the use of BFD's seemed potentially reasonable, but do recognize it would correspondingly require broader coordination which could complicate the effort beyond reason. So possibly as the parameters required to sufficiently describe the logically visible debug model of an arbitrarily configured processor subsystem becomes clear, these same parameters could be considered to form the basis of a more centralized target configuration description which may ultimately be utilized by other tools.