Re: [rfa] Fix software-watchpoint failures by adding epilogue detection

[Daniel Jacobowitz <dan@codesourcery.com>]

On Fri, Sep 24, 2010 at 02:39:05PM +0200, Ulrich Weigand wrote:
> 1. Some epilogue sequences accepted by your patch were not accepted by mine:
> - My patch only accepted "bx lr" as return, while yours accepts any "bx".
> - I had a typo in one of the instruction opcodes.
> 
> 2. Some epilogue sequences accepted by my patch were not accepted by yours:
> - I'm allowing "mov sp, r7" and "vldm" instructions, as well as certain
>   additional cases of "ldm.w".

These all sound good.

> - I'm accepting more diverse sequences due to forward-scanning for multiple
>   instructions, and not requiring backward-scanning.

This I'm worried about.  From my patch:

+  /* We are in the epilogue if the previous instruction was a stack
+     adjustment and the next instruction is a possible return (bx, mov
+     pc, or pop).

This is definitely an epilogue:

  pop { r4, r5, r6, lr }
  bx lr

This could be an epilogue, but it could also be an indirect call:

  bx lr

If it's an indirect call there would be a mov lr, pc before it.
If it's an indirect tail call, then it's an epilogue, and the return
address won't be saved.

If there's no stack adjustment, then gdbarch_in_function_epilogue_p
does not need to return 1; the predicate really means "we can not
check for watchpoints because the frame might be in an inconsistent
state".

Is it safe for this predicate to return 1 around something that is not
an epilogue?

Given that definition of the predicate, the backwards scan is
appropriate; without a backwards scan, we can only answer "is there an
epilogue after this point", not "are we already inside an epilogue".

Of course, if it turns out harmless to return false positives... I'm
not sure.

-- 
Daniel Jacobowitz
CodeSourcery