Seems like a bug in target_read_stack / dcache_xfer_memory?
Michael Snyder
msnyder@vmware.com
Mon Oct 19 17:49:00 GMT 2009
drow@false.org wrote:
> On Sun, Oct 18, 2009 at 03:31:53PM -0700, Michael Snyder wrote:
>> The arguments and return
>> value are just as for target_xfer_partial
>
> The comment is on the logical home of this method, other places should
> refer to the header: the definition of to_xfer_partial in struct
> target_ops in target.h.
OK, shouldn't we say so? I want to drop this conversation,
though, and focus on the code problem. Sorry again for my
aggrieved tone yesterday -- I was tired. ;-(
>> Anyway, I don't even remember now how I figured this out, but
>> I *THINK* what all these guys return is either 0 for success,
>> or an errno value less than zoro.
>
> No, they return:
>
> the number of bytes actually transfered, zero when no
> further transfer is possible, and -1 when the transfer is not
> supported.
OK, so suppose dcache_xfer_memory returns zero in this context.
That means no transfer is possible. Shouldn't we give the other
targets on the stack a shot?
In the case I'm looking at, the next target down is a core file,
and I know it has the memory location available. If I force gdb
out of this error return, core_xfer_partial will succeed.
More information about the Gdb-patches
mailing list