From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28417 invoked by alias); 7 May 2005 04:30:34 -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 28389 invoked from network); 7 May 2005 04:30:31 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 7 May 2005 04:30:31 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DUGxR-0007fi-CH; Sat, 07 May 2005 00:30:29 -0400 Date: Sat, 07 May 2005 04:30:00 -0000 From: Daniel Jacobowitz To: Paul Schlie Cc: gdb@sourceware.org Subject: Re: Available registers as a target property Message-ID: <20050507043029.GA29449@nevyn.them.org> Mail-Followup-To: Paul Schlie , gdb@sourceware.org References: <20050507013640.GA26032@nevyn.them.org> 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/msg00085.txt.bz2 On Fri, May 06, 2005 at 11:49:00PM -0400, Paul Schlie wrote: > 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. Personally I don't think it's very useful. I'm not sure why you call them "semi-customizable"; the point is that they are, in fact, fully customizable. ARM's approach to this problem was to encapsulate the description in the module server, which is distributed with the target configuration. Anything that wants the configuration can query the target for it. That seems a lot more useful to me - rather than centralizing the registry, distribute it locally to every target it describes. -- Daniel Jacobowitz CodeSourcery, LLC