Re: Flash support part 1: memory maps

[Daniel Jacobowitz <drow@false.org>]

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