Re: [rfc] Correct semantics of target_read_partial, add target_read_whole

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Wed, 21 Jun 2006 23:23:55 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> Originally, target_read_partial was supposed to read "however much it could
> manage to" and then higher level functions were supposed to handle the rest.
> But every existing implementation always reads enough data in its first
> call; the one remote protocol implementation did so by issuing as many
> packets as necessary, which defeated the point of the original design.

Ah, it all makes sense to me now.  I'm wondering whether we should
"export" target_read_partial() (and target_write_partial()) at all.
It's never right to use them except for implementing higher-level
target read/write functions isn't it?

> This patch adjusts the remote protocol layer not to do that.  It also
> promotes a useful function from auxv.c to target.c:
> 
> +/* Wrappers to perform a full read of unknown size.  OBJECT/ANNEX will
> +   be read using OPS.  The return value will be -1 if the transfer
> +   fails or is not supported; 0 if the object is empty; and the length
> +   of the object otherwise.  If a positive value is returned, a
> +   sufficiently large buffer will be allocated using xmalloc and
> +   returned in *BUF_P containing the contents of the object.
> +
> +   This method should be used for objects sufficiently small to store
> +   in a single xmalloced buffer, when no fixed bound on the object's
> +   size is known in advance.  Don't try to read TARGET_OBJECT_MEMORY
> +   through this function.  */
> +
> +extern LONGEST target_read_whole (struct target_ops *ops,
> +                                 enum target_object object,
> +                                 const char *annex, gdb_byte **buf_p);
> 
> When you use to_xfer_partial to get at memory, obviously you don't want "the
> whole object".  But for other objects, such as auxv vectors or XML
> description files, usually you do.  This provides a central interface
> to handle short reads correctly, instead of letting that code circulate
> (buggily in many cases) through other files.

Agreed.  I have a (small) concern that the introduction of
target_read_whole() will cause confusion with target_read().  Perhaps
a better name would be target_read_alloc?

You might consider commiting the sparc-tdep.c change seperately; it's
"obvious".

Mark