Re: [PATCH] add 'rs6000_in_function_epilogue_p()'

[Jim Blandy <jimb at red-bean dot com>]

On 12/2/05, Daniel Jacobowitz <drow@false.org> wrote:
> > 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...

I've been loose with my words, so what I'm describing may not
correspond exactly to what I've said before, or to what Paul has
posted, so erase all that and read afresh.

If you call rs6000-tdep.c skip_prologue to analyze a live frame, with
'pc' being the function's entry point and 'lim_pc' being the current
PC within that function, then sometimes the analysis won't reach
lim_pc; it'll hit some branch or unrecognized instruction.  In that
case, we just give up and hope that the information we've gathered so
far would still be accurate if we had been able to analyze all the way
to lim_pc.

But we can do a bit better than that.  If skip_prologue were sure that
lim_pc represents a real PC value (its callers know), and scanning
from the entry point wasn't able to reach lim_pc, and lim_pc points
directly at a return instruction, then we *know* that the current SP
is our CFA.  And if you actually understand all the instructions
between lim_pc and the return instruction, then you may again be able
to derive the CFA.  This information can be used in preference to that
obtained with the from-entry-point scan.

To put it another way, there are two cases where we can be pretty
confident our machine code analysis has gotten us the straight dope:
when we recognize everything from the entry point to lim_pc, and when
we recognize everything from lim_pc to a return instruction.  In the
first case, we can run backwards from lim_pc to reconstruct the state
when we were at the entry point; in the second case, we can run
forwards from lim_pc to construct the state we'll be at when we
return.  Either one is equivalent, for our concept of unwinding.

If we moved Paul's heuristic (actually, it's a bit loose for my tastes
too, so maybe something tighter) into skip_prologue, we could solve
the watchpoint problem, and also improve backtraces, which will also
be broken in the midst of the epilogue (if they weren't then
watchpoint_check wouldn't be unhappy).