Re: Seems like a bug in target_read_stack / dcache_xfer_memory?

[Daniel Jacobowitz <drow@false.org>]

On Mon, Oct 19, 2009 at 10:43:24AM -0700, Michael Snyder wrote:
> 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.   ;-(

Sure - I'm just as annoyed by the tangle as you are - I just remember
hunting for this comment myself :-)

> 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.

You haven't really described the situation, so I'm guessing.  But the
problem can't be in the code you cited.  It's got to be further down
the call stack.

-- 
Daniel Jacobowitz
CodeSourcery