This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] add 'rs6000_in_function_epilogue_p()'
- From: Paul Gilliam <pgilliam at us dot ibm dot com>
- To: gdb-patches at sourceware dot org
- Cc: Jim Blandy <jimb at red-bean dot com>, gdb-patches at sources dot redhat dot com
- Date: Thu, 1 Dec 2005 10:57:59 -0800
- Subject: Re: [PATCH] add 'rs6000_in_function_epilogue_p()'
- References: <200511301225.56802.pgilliam@us.ibm.com> <8f2776cb0511302121k4b750269l4316b1e13a41debc@mail.gmail.com>
- Reply-to: pgilliam at us dot ibm dot 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 #=-