This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Correct semantics of target_read_partial, add target_read_whole
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: drow at false dot org
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 22 Jun 2006 20:24:54 +0200 (CEST)
- Subject: Re: [rfc] Correct semantics of target_read_partial, add target_read_whole
- References: <20060622032355.GA27566@nevyn.them.org>
> 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