Re: [PATCH] add 'rs6000_in_function_epilogue_p()'

[Paul Gilliam <pgilliam@us.ibm.com>]

On Wednesday 30 November 2005 21:21, Jim Blandy wrote:
> I'm not objecting to the patch, but following the links to the other
> messages I didn't really see an explanation as to how incorrectly
> recognizing the prologue causes the watchpoints to be deleted early. 
> I assume we're talking about a case like:
> - we're in some function foo
> - we set a watchpoint on one of its local variables
> - we step through a call from foo to bar
> - as we exit bar, the watchpoint gets deleted, even though it's in the
> frame we're returning to, not the frame that is exiting.
> 
> Is that right?  How does correctly recognizing the prologue fix this?
> 
> 

You have it, that's exactly what's going on.

The reason the watchpoint gets deleted when exiting bar is that
'watchpoint_check' ("breakpoint.c":2480) thinks that the watched variable
is out of scope.  It thinks that because once the stack pointer has been diddled
with in the functions epilogue, 'frame_find_by_id' ("./frame.c":394) is unable to find
frame where the variable is active.  It is unable to do so because when scanning
through the frames, 'get_frame_id' ("./frame.c":333) returns a frame_id with the 
correct 'stack_addr' but with the wrong 'code_addr'.  The 'code_addr' is for the 
function being exited instead of the function being returned to.

When the frame where the variable is active can not be found,
'gdbarch_in_function_epilogue_p' is called to see if execution is in an epilogue.  If it is
'watchpoint_check' just returns 'no change'.  Once execution gets out of the epilogue
by returning, 'get_frame_id' does the right thing again and everything is good.

The default 'gdbarch_in_function_epilogue_p' always just says no.  By defining
'rs6000_in_function_epilogue_p' and puting it's address into the arch. vector, the
correct determination is made and the bug is fixed.

-=# Paul #=-