From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 821 invoked by alias); 26 Jan 2006 15:08:44 -0000 Received: (qmail 813 invoked by uid 22791); 26 Jan 2006 15:08:43 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-03.spheriq.net (HELO fra-del-03.spheriq.net) (195.46.51.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jan 2006 15:08:40 +0000 Received: from fra-out-01.spheriq.net (fra-out-01.spheriq.net [195.46.51.129]) by fra-del-03.spheriq.net with ESMTP id k0QF8cMB001926 for ; Thu, 26 Jan 2006 15:08:38 GMT Received: from fra-cus-02.spheriq.net (fra-cus-02.spheriq.net [195.46.51.38]) by fra-out-01.spheriq.net with ESMTP id k0QF8b1I021219 for ; Thu, 26 Jan 2006 15:08:37 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-02.spheriq.net with ESMTP id k0QF8ZQ5019016 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 26 Jan 2006 15:08:36 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1FC5DDA4E for ; Thu, 26 Jan 2006 15:08:35 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1D8C0473FF for ; Thu, 26 Jan 2006 15:12:06 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CHE09753 (AUTH stubbsa); Thu, 26 Jan 2006 15:08:33 GMT Message-ID: <43D8E573.1060004@st.com> Date: Thu, 26 Jan 2006 16:24:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Using XML in GDB? References: <20060126055744.GA29647@nevyn.them.org> <43D8BB89.4090900@st.com> <20060126134124.GA3107@nevyn.them.org> In-Reply-To: <20060126134124.GA3107@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.0 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00265.txt.bz2 Daniel Jacobowitz wrote: > There isn't a definitive conclusion because it's evolved substantially > once I began (re-) implementing it. This is what I had two weeks ago: > > http://sourceware.org/ml/gdb/2005-05/msg00171.html > > But it doesn't look entirely like that any more. > > Registers can be generically described without hard-coded GDB > knowledge. Most other features can't, except for their presence or > absence. But the point of suggesting XML is to keep this extensible > should someone have a bright idea :-) That sounds good. We have been considering doing something with memory mapped registers (devices, exception/interrupt reason codes, etc.), and this might be the answer. More generally we have been looking at ways to pass back information about the target to replace the GDB scripts we currently use that just trust that the target is as they describe - there is no check that the user hasn't connected to the wrong type. You may remember that my proposal concerning a plugin interface provided means for the target plugin to run GDB commands. This was one way I planned to solve this problem. Specifically, the data we need/want GDB to know about the target are as follows: - architecture variant (i.e. what registers and instructions are valid); - endian; - memory map (not that GDB seems to do much with this at present); - non-core control/information registers; - other features. 'Other features' includes simulator specific trace features, silicon specific performance measurement devices, low level jtag commands etc. These things are controlled through custom GDB commands that may or may not be available on any given target. In general, there is a selection of GDB 'set' commands which are of interest to targets and for which an interface might be nice. None of this directly addresses the question of XML, but it does represent the sort of thing (some) users are looking to do, and therefore what 'extensibility' might entail. Of course, I'm still not sure exactly what you envisage as the limits of the interface. Speaking of XML, are you aware of the SPIRIT SOC definition standard (http://www.spiritconsortium.com) which contains some things that the debugger might be interested in (and much in which it is not). I've no idea how compatible they are, but it might be nice if GDB could pull relevant information out of one of these. Thanks Andrew Stubbs