From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22306 invoked by alias); 10 May 2005 00:54:36 -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 22069 invoked from network); 10 May 2005 00:54:27 -0000 Received: from unknown (HELO calvin.codito.co.in) (220.225.32.98) by sourceware.org with SMTP; 10 May 2005 00:54:27 -0000 Received: from [192.168.100.52] (arnor.codito.co.in [192.168.100.52]) by calvin.codito.co.in (8.12.10/8.12.10) with ESMTP id j4A0s04H028877; Tue, 10 May 2005 06:24:02 +0530 Message-ID: <42800617.3090701@codito.com> Date: Tue, 10 May 2005 00:54:00 -0000 From: Ramana Radhakrishnan User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sourceware.org Subject: Re: RFC: Available registers as a target property References: <20050506162029.GA30792@nevyn.them.org> In-Reply-To: <20050506162029.GA30792@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00130.txt.bz2 Hi, > Also, it operates at an "optional feature" level rather than an "optional > register" level. The ARM RDI protocol has a nifty feature called > Self-Describing Modules, which allows coprocessors to describe themselves to > the debugger, including describing their register sets. It includes both > user-level information (name and type - along with a complicated type > description language) and implementation information (like the ARM mode in > which the register is accessible, for banked registers). I would like > the GDB solution to this problem to be sufficiently flexible to work with > SDM - both because it's a nice model and because that way we can be > compatible with ARM debug servers, given an adequate RDI proxy. On the ARC there are extension encoding sections (Look at .arcextmaps created in binutils for extension directives. ) which describe such registers by the binary. Its possible to rename registers with other names and to specify other such names for auxiliary registers. Using such a mechanism would definitely be useful . Again its possible that the same registers appear with different data formats in different configurations of the core. > DETAILS > ======= > > First of all, the target object. It can describe either individual > registers or register sets known to the target (for brevity). Each > component is an ASCII string. Colon is used as a field delimiter and > semicolon as a component delimiter. A register set would look like: > > set:: > > No more information is necessary; the register set is an abbreviation of a > well-defined group of registers that both the stub and GDB have external > knowledge of. GDB will already know the order, types, and sizes of > registers, and potentially other details (such as how to pass them as > arguments to functions). If GDB does not recognize the register set, it can > safely ignore it, but should issue a warning to the user recommending use of > a later GDB. If the protocol does not require numbers, they will be > ignored, but they are non-optional in the syntax. > > I have spent less time thinking about how to specify individual registers. > This should suffice, but if anyone can see cause for another standard field, > please speak up. > > reg:::::... > > Types unknown to GDB would default to integral display; common types such as > integral, floating point (native byte order), integral vector, fp vector, et > cetera would be documented in the manual with fixed names. Can one add a gdbarch_defined_type where the arch interprets the raw bit stream to provide the user with a decent view of the registers . It so happens that there are many status registers which are essentially bitfields , so having this as a hook for gdbarch to use for printing register values might be useful. An example where this could be used would be printing the status flags for e.g. on the i386. (One could print the ZNCV values automatically. ) Also a way of describing reggroups in this protocol would be very useful and conditions underwhich these are allowed to exist would be something interesting. (would typically be the presence of a sequence of bits in some bcr obtainable by basic bitwise arithmetic on some BCR values. ) cheers Ramana -- Ramana Radhakrishnan GNU Tools codito ergo sum (www.codito.com)