This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Flash support part 1: memory maps
- From: Daniel Jacobowitz <drow at false dot org>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: vladimir at codesourcery dot com, eliz at gnu dot org, gdb-patches at sources dot redhat dot com
- Date: Mon, 31 Jul 2006 20:53:33 -0400
- Subject: Re: Flash support part 1: memory maps
- References: <200607201341.34070.vladimir@codesourcery.com> <uhd1bgf2m.fsf@gnu.org> <200607311700.42502.vladimir@codesourcery.com> <200607311720.26487.vladimir@codesourcery.com> <200607312208.k6VM82PM012536@elgar.sibelius.xs4all.nl>
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