Re: mips-tdep.c: Fix sw watchpoint-out-of-scope events

["Maciej W. Rozycki" <macro@mips.com>]

On Wed, 19 Sep 2007, Daniel Jacobowitz wrote:

> Could you give me an example?  The watchpoint shouldn't go out of
> scope before the scope breakpoint is hit.  The problem is, instead,

 Well, the scope breakpoint is set up in the caller of the function 
providing the frame containing the variable being watched.  So by 
definition at the point it is hit the watchpoint has always gone away 
already.  This is how it works with hw watchpoints.

> that it appears to change value.  There's two cases.  In the epilogue
> of the function containing the watched variable, the stack frame gets
> destroyed, so the watchpoint is no longer valid... but we don't have
> any marker to indicate that.  In the epilogue of other called
> functions, the watchpoint is still valid but we fail to backtrace
> correctly so we don't find the original function on the stack.

 Correct.  There is actually a third case which is somewhere inbetween -- 
where the function containing the watched variable ends by jumping to a 
sibling call.  For a C program from the language's point of view the 
watchpoint is still in the scope during the execution of the sibling call, 
while in reality its stack frame has gone away already.

> Both of these can happen for hardware watchpoints too, e.g., if the
> user is single stepping or has other breakpoints set.  In practice
> they rarely do.

 True.

> I think I wasn't clear.  I'm asking if returning to the original call
> line, the way MIPS o32 PIC does, should be a PASS.  Other platforms
> that have teardown after function calls will show the same behavior.

 Well, that sounds reasonable given the complication around getting things 
perfect here.  Ideally the out-of-scope event should happen at the same 
place where "finish" from the function in question would stop; in my 
opinion at least.

  Maciej