This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Daniel Jacobowitz wrote:


> +/* 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);

Is there any reason why 'target_read_whole' calls 'target_read', as opposed
to calling 'target_read_partial' directly? I mean, if target_read_whole can
do several reads itself, there's no point to use 'target_read'.

- Volodya





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]