Re: Seems like a bug in target_read_stack / dcache_xfer_memory?

[Michael Snyder <msnyder@vmware.com>]

Daniel Jacobowitz wrote:
> 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.

Can you explain why it can't be in the code that I cited?
I don't understand why, for instance, this scenario couldn't
apply:

  * memory_xfer_partial is called for a stack-like location
    (say, 4 bytes beyond the topmost frame).
  * inf is non-null,
    region->attrib.cache is true or
    stach_cache_enabled_p and object == TARGET_OBJECT_STACK_MEMORY
  * therefore we call dcache_xfer_memory,
  * The requested location isn't cached, so we return zero.



----
However, of course I'll describe the situation.  You can't
quite replicate it yet, unles you've applied my recent patches.

1) load testsuite/gdb.reverse/solib-reverse
2) break main
3) record
4) until 41
5) record save foo
6) record restore foo (this kills the running process,
    loads the core file/log, and puts you back at main)
7) until 41

The "until" command tries to read beyond the top of stack,
which is fine for the running process and fine for the core
file, but for some reason in this instance wants to go into
dcache, where nothing currently should be cached.