From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9920 invoked by alias); 10 May 2005 11:12:13 -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 9783 invoked from network); 10 May 2005 11:12:05 -0000 Received: from unknown (HELO rwcrmhc14.comcast.net) (216.148.227.89) by sourceware.org with SMTP; 10 May 2005 11:12:05 -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 <2005051011120301400fp2oee>; Tue, 10 May 2005 11:12:04 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 10 May 2005 11:12:00 -0000 Subject: Re: RFC: Available registers as a target property From: Paul Schlie To: Chris Zankel , Daniel Jacobowitz , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00133.txt.bz2 > I was thinking about an architecture with multiple configurations (registers), > such as Arc, Tensilica, ARM coprocessors (?), etc. > Having a single daemon supporting these multiple (arbitrary) configurations > would probably be easier for JTAG probe vendors. Since GDB certainly needs to > know about the particular configuration, the daemon wouldn't need to be > modified for each configuration. > >> I don't want to support both directions just for kicks, but there may >> be value here that I haven't thought of yet. That's why I asked >> Tensilica for feedback. > > I understand. I was just wondering if this would be useful and actully agree > that your proposal makes much more sense and that the target should know about > the configuration. > > In our case, the daemon currently doesn't know about a particular > configuration, and GDB only queries for registers the processor (better) has. > For example, to read 'special register' , OCD simply issues a rsr a2, > and doesn't know if this really exists. It seems that there are two fundamental models which may be adopted: - refine GDB to be fully architecturally neutral, whereby all target specific architectural details are provided by the target; including but not limited to binary code encoding format, disassembly definitions, type encoding definitions, symbolic and semantic register definition, specification logical register names, types, purpose {GP pointer/data, SP, FP, PC, SR, etc. including their encoding {endian, signess, fixed/ floating point encoding}}, logical/physical memory space definition address range, address resolution, segmentation, etc.}, not to mention potentially countless control registers which may be present to control the cache, MMU, FPU, etc. configurations, and/or operating modes; and possibly even the target interface protocol specification. - refine GDB to enable these various potential target specific details to be extracted from a target definition/configuration binary specification directly, likely as directed by the user and possibly further refined after subsequently querying the target. Essentially leaving the target interface to be primarily responsible for GDB <=> target protocol translation, being essentially analogous to the driver for an I/O device) (Although not vastly dissimilar, it likely boils down to where one wants to draw the line between the division of responsibility between the debugger and the target interface processes; where personally regardless of where, I simply believe all target architectural specification information should be consolidated for the benefit of other tools, rather than being scattered all over the place, or rely on proprietary sources of this information, being "hidden" in a "propriety target interface".)