From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20904 invoked by alias); 1 Aug 2006 00:53:44 -0000 Received: (qmail 20831 invoked by uid 22791); 1 Aug 2006 00:53:43 -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; Tue, 01 Aug 2006 00:53:41 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G7iVp-0006Yq-Ko; Mon, 31 Jul 2006 20:53:33 -0400 Date: Tue, 01 Aug 2006 00:53:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: vladimir@codesourcery.com, eliz@gnu.org, gdb-patches@sources.redhat.com Subject: Re: Flash support part 1: memory maps Message-ID: <20060801005333.GB24099@nevyn.them.org> Mail-Followup-To: Mark Kettenis , vladimir@codesourcery.com, eliz@gnu.org, gdb-patches@sources.redhat.com References: <200607201341.34070.vladimir@codesourcery.com> <200607311700.42502.vladimir@codesourcery.com> <200607311720.26487.vladimir@codesourcery.com> <200607312208.k6VM82PM012536@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607312208.k6VM82PM012536@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00001.txt.bz2 I'll let Vlad answer most of this, but there's one bit I'm responsible for, so I'll give it a shot :-) On Tue, Aug 01, 2006 at 12:08:02AM +0200, Mark Kettenis wrote: > I'm still not sure how this fits in. Certainly if my target already > provides a memory map in a nice data structure I'm not supposed to > convert that into XML am I? I should be able to just implement > to_memory_map and convert it directly into a VEC(memory_region). Right. You wouldn't have to implement TARGET_OBJECT_MEMORY_MAP at all in that case. I wrestled with this a while for self-describing targets. We needed a way for users to specify the memory maps: both by hand, as final end users, and automatically, as remote stub developers. We want to use the same format for both of those, so there needs to be a single defined format to write these things in. We picked XML, so there's a DTD (Document Type Description) and you can automatically validate maps, et cetera. Then there's another format for GDB to work with internally, as a C data structure. The C data structure doesn't lend itself to the to_xfer_partial interface well at all; there's memory allocation issues, for instance. Rather than pass the binary data around through to_xfer_partial, or invent yet another mechanism for reading special data from the target, I ended up passing it through what has now become target_read_alloc. This spared me having to deal with things like packet size limits and partial transfers. So what I ended up with was a standard implementation of to_available_features (similar role to to_memory_map here). That lives in some code which isn't specific to the remote backend, but the remote backend chooses to use it to implement remote_ops.to_available_features. Other backends might choose to do that too, and provide XML, or implement to_available_features directly. It is a little twisty and redundant, but I couldn't see a better way. If you do, I'm all ears :-) > You really don't have to say things twice ;-). I bet SVK has this bug too... when you do "svn diff | patch -p0 -R" it leaves empty files by default because it doesn't bother to fill out enough of the diff header :-( -- Daniel Jacobowitz CodeSourcery