Re: RFC: Available registers as a target property

[Daniel Jacobowitz <drow@false.org>]

On Sat, May 07, 2005 at 10:35:02PM +0300, Eli Zaretskii wrote:
> > Thinking about it now, the parsing could be pushed down into the remote
> > protocol implementation, and a C structure returned as a binary blob
> > via target_read_partial.
> 
> That's what I had in mind, sort of.
> 
> > Do you think that would be a better interface to choose?
> 
> I think so, but it's an idea based on general principles; I know much
> less than you about the remote targets.  So if you find that what I
> suggested has any significant drawbacks, I won't insist.

I've thought about this some more.  I see one drawback, but it is
definitely solvable.

The data structure is not readily fixed-size.  The target-specific data
has no specified format, so it will be a binary (or probably ASCII)
blob; the common format data will include character strings, e.g. the
names of registers, which will have to be allocated somewhere.  We
don't want to leak them, so they need to have a defined lifetime.

The target_read_partial interface is not well suited to that because
the data may be transfered in multiple chunks; each time, we call down
to the target.  The best thing I can think of would be to create the
data structure once in the target, store it persistently, and then feed
bits of that data structure back via to_xfer_partial.  This requires
mutable data attached to the target object.  Nowadays we can use
target_ops:to_data for this, so that should be OK.

This lets the target control the data lifetime.  Handy, since it allows
for const structures for simulator targets, where we know the available
features at compile time.

So that should work OK.

-- 
Daniel Jacobowitz
CodeSourcery, LLC