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: Seems like a bug in target_read_stack / dcache_xfer_memory? 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

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.

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