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

["Ulrich Weigand" <uweigand@de.ibm.com>]

Daniel Jacobowitz wrote:

> On Fri, Sep 24, 2010 at 02:39:05PM +0200, Ulrich Weigand wrote:
> > - 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.

I'm wondering how "bx lr" could be an indirect call; for a call,
lr would have to point to the return address, so it couldn't also
contain the target address ...  Am I missing something here?

My original patch accepted only specifically "bx lr"; yours also
accepts different registers for bx.  If we have a bx with a
different register, this may of course well be an indirect call.

As far as I can see, GCC never uses bx with any other register but
lr to implement a return instruction.  Do you know whether this is
also true for other compilers?  If so, maybe the easiest fix would
be to change this back to only accepting "bx lr".

> 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.

It seems to me that it is relatively harmless to return a false positive;
the only thing that happens is that the check for watchpoint hits is
delayed until the next instruction.  In particular, returning true in
the epilogue of a frameless functions should definitely be harmless.
(Returning true on a bx that implements a function call might in rare
cases lead to a watchpoint hit being detected on the first instruction
of the called function instead ...)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com