This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Seems like a bug in target_read_stack / dcache_xfer_memory?
- From: Michael Snyder <msnyder at vmware dot com>
- To: Michael Snyder <msnyder at vmware dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 19 Oct 2009 10:43:24 -0700
- Subject: Re: Seems like a bug in target_read_stack / dcache_xfer_memory?
- References: <4ADB9759.7060305@vmware.com> <20091018225134.GA30546@caradoc.them.org>
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.