From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14739 invoked by alias); 26 Jan 2006 20:48:16 -0000 Received: (qmail 14731 invoked by uid 22791); 26 Jan 2006 20:48:16 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 26 Jan 2006 20:48:14 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F2E2O-0004U8-JB; Thu, 26 Jan 2006 15:48:12 -0500 Date: Thu, 26 Jan 2006 20:52:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb@sourceware.org Subject: Re: Using XML in GDB? Message-ID: <20060126204812.GA16966@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb@sourceware.org References: <20060126055744.GA29647@nevyn.them.org> <200601262036.k0QKaXJl007966@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601262036.k0QKaXJl007966@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i 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/msg00277.txt.bz2 On Thu, Jan 26, 2006 at 09:36:33PM +0100, Mark Kettenis wrote: > > Date: Thu, 26 Jan 2006 00:57:44 -0500 > > From: Daniel Jacobowitz > > > > Hi folks, > > > > I've spent the last week and a half working on the "target available > > feature" interface that I described on this list last May. A big chunk > > of the last two days has been spent trying to nail down a useful format > > to store (in files) and transfer (over the remote protocol) descriptions of > > remote "features", especially their register sets. > > > > At first I was primarily focused on compactness. But I've got a pretty good > > handle on that problem now; a well-defined naming scheme and some caching, > > and the size of the data is no longer a major concern. > > Does that hold for slow serial links too? Yes. Here's how it works in my current design: - GDB connects to the target. - GDB queries the target for its features. - The target replies briefly (basically just name and a base integer for register numbering). - GDB looks up the features by name in the set of features it recognizes. - GDB queries the target for any features it does not recognize. - GDB caches the queried features (with some exceptions). The cache could be either in RAM, or on disk if desired and configured. Suppose a verbose, well-documented register description is 50K - my current (non-XML, but also non-verbose) descriptions are only about 2K. Over a 9600 baud serial link, which is about the slowest we're likely to encounter, this could take about a minute to transfer - the first time. That would be a good motivation to use the on-disk caching and maybe a progress indicator. Most of my current debug targets have higher bandwidth links than that, although often with a very high latency; I've got some tricks up my sleeve for reducing the impact of latency, too (coming soon to a gdb@ near you). > > And we get all sorts of things for free; for instance, UTF-8, which will be > > handy if someone ever wants to include internationalized descriptions in the > > target description. > > > > Does anyone have a good reason why GDB should not make use of this > > well-standardized format instead of inventing additional ad-hoc formats? > > No objection to using a well-standardized format, but that probably > only makes sense if you're not going to write your own parser. And I > really would like to avoid making GDB dependent on a library that > isn't standardly available on all systems we support. I definitely have no intention of either writing my own XML parser or introducing an external dependence. I am tentatively planning to import one of {expat, libxml2} into src/ and arranging for it to be built as necessary. Sadly there does not seem to be a GNU implementation of an XML parser with C bindings; I only found Java bindings. If anyone knows to the contrary, please holler. -- Daniel Jacobowitz CodeSourcery