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()'
On Fri, Dec 02, 2005 at 02:19:07PM -0800, Jim Blandy wrote:
> On 12/2/05, Paul Gilliam <pgilliam@us.ibm.com> wrote:
> > This patch does *not* assume that the exit of the function is near the end of the function.
> >
> > It's more/less of a hack than that!
> >
> > Here is the 'algorithm':
> > 1) scan forward from the point of execution:
> > a) If you find an instruction that modifies the stack pointer, execution is not in an epilogue, return.
> > b) Stop scanning if you find a return instruction or reach the end of the function.
> > 2) scan backward from the point of execution:
> > a) If you find an instruction that modifies the stack pointer, execution *is* in an epilogue, return.
> > b) Stop scanning if you reach the beginning of the function.
> (That text belongs in a comment, else Daniel wouldn't have got it wrong!)
For all sorts of reasons, this isn't a safe algorithm; just a guess.
- A forward scan really has to stop at any control flow instruction.
- A backward scan, in general, is just not possible. GCC does
agressive basic block reordering and tail merging, and will do
more so in the future; who knows where you came from...
It may be a useful guess though.
> You know, there's no reason this logic wouldn't be equally useful in
> the skip_prologue function. If the prologue scan doesn't make it to
> the PC, then we could do the above, and use it to provide an accurate
> frame ID. That would fix the bug, and backtraces too.
I don't think I follow...
Anyway, there is exactly this one user of the method. It occured to me
that there may be a better way to figure out what we _really_ want to
check there. We want to know "is this watchpoint in a stack frame that
isn't there any more". A gdbarch method that knows whether we're above
or below the stack pointer...
But this all gets tangled up in what we're _really_ watching. We want
to watch the local variable, which may move around - we get the
"multiple locations" (loclist) case completely wrong today.
--
Daniel Jacobowitz
CodeSourcery, LLC