Re: [PATCH] add 'rs6000_in_function_epilogue_p()'

[Daniel Jacobowitz <drow@false.org>]

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