From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32737 invoked by alias); 7 May 2005 15:19:23 -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 32638 invoked from network); 7 May 2005 15:19:15 -0000 Received: from unknown (HELO sccrmhc11.comcast.net) (204.127.202.55) by sourceware.org with SMTP; 7 May 2005 15:19:15 -0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc11) with SMTP id <2005050715190501100jp9ome>; Sat, 7 May 2005 15:19:15 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 07 May 2005 15:19:00 -0000 Subject: Re: Available registers as a target property From: Paul Schlie To: Daniel Jacobowitz CC: Message-ID: In-Reply-To: <20050507054054.GA31247@nevyn.them.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00090.txt.bz2 > From: Daniel Jacobowitz >> On Sat, May 07, 2005 at 12:53:48AM -0400, Paul Schlie wrote: >> - actually arm "extensible architecture" is fairly rigid, and arguably >> far less "customizable" than those offered by ARC or Tensilica for >> example; and is likely best characterized as being extended via >> co-processor extensions not an innate extension/customization of the >> arm ISA or processor implementation core architecture itself. > > ... which GDB also needs to support. > >>> 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. >> >> - so you propose that GNU tools adopt a reliance on a proprietary vendor >> data base "module server" in order to configure tools to support that >> vendors proprietary licensed architecture? > > Please limit yourself to constructive comments instead of accusations; > it's apparent that you aren't familiar with RDI (not surprising, since > I don't believe the documentation is publicly available), and that you > haven't really thought about what I'm suggesting. Hint: all the > necessary information can be provided by gdbserver, and will be. Linux > KGDB stubs also have enough information to provide this data, and > hopefully will once GDB supports it. I'm sure some free software > simulation systems will also. > > We've gotten way off topic at this point. I don't dispute the necessity to enable a more detailed description of a target's configuration (as you have pointed out that many multiple variants may exist). I was just attempting to suggest that such information, as it's likely useful to multiple tools, may ideally be formalized and accessible in a more centralized open manor such that for example it may be directly accessed by GDB, as opposed to relying on a remote target to supply it; as that seems like a potentially slippery slope, where if that trend continued, GDB would become not much more than a user/control interface for a "remote" proprietary debugger, which doesn't seem like a good thing or direction? (thanks for hearing me out, I just wanted to make the observation.)