This is the mail archive of the 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: supporting all kinds of partially-<unavailable> enum target_object types

On 10/25/2013 12:15 AM, Pedro Alves wrote:
We could do that by changing target_xfer_partial's
interface from:

     LONGEST (*to_xfer_partial) (struct target_ops *ops,
				enum target_object object, const char *annex,
				gdb_byte *readbuf, const gdb_byte *writebuf,
				ULONGEST offset, LONGEST len);


     int (*to_xfer_partial) (struct target_ops *ops,
				enum target_object object, const char *annex,
				gdb_byte *readbuf, const gdb_byte *writebuf,
				ULONGEST offset, ULONGEST len, ULONGEST *read_count);

Where the target implementation would write how many bytes were read
to *READ_COUNT, instead of returning it. (The int return would then be just
be success/error, instead of the read length.)

How about "XFERED_COUT" or "XFERED_LEN"? since it may be used by write.

Current to_xfer_partial returns one of three states, read length (> 0), done (0), and error (< 0). to_xfer_partial could return an enum to represent these status, e.g.,

enum target_xfer_status


When TARGET_XFER_OK is returned, *XFERED_COUNT is the number of bytes read from target. When TARGET_XFER_DONE is returned, to_xfer_partial can't handle this request. When TARGET_XFER_ERROR_XXX are returned, *XFERED_COUNT is set properly.

What do you think about the interface like this?

When returning TARGET_XFER_E_UNAVAILABLE, we'd return in
*READ_COUNT the number of unavailable bytes "read", or IOW, where
the next non-<unavailable> byte is, or LEN, if that comes before.

So the (**1) case above would return TARGET_XFER_E_UNAVAILABLE
with *READ_COUNT set to 50.

target_read_memory would be likewise adjusted, or a variant added.
And then, in specific case of values, read_value_memory would not have that
available_memory vector or any traceframe_number check, but instead
would call target_read_memory in a loop, and if TARGET_XFER_E_UNAVAILABLE
comes out, it'd mark READ_COUNT value bytes unavailable starting at
the requested address, and then continue reading from the previous
addr + READ_COUNT, rinse repeat, until the whole value was read in.

This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target.  (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could

IIUC, each target (tfile and remote, for example) should fetch traceframe_info in its to_xfer_partial implementation, to decide whether to return TARGET_XFER_E_UNAVAILABLE, right?

Yao (éå)

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