Re: Seems like a bug in target_read_stack / dcache_xfer_memory?

[Michael Snyder <msnyder at vmware dot com>]

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.