This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfa] Fix software-watchpoint failures by adding epilogue detection
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: dan at codesourcery dot com (Daniel Jacobowitz)
- Cc: gdb-patches at sourceware dot org, rearnsha at arm dot com
- Date: Tue, 28 Sep 2010 18:04:14 +0200 (CEST)
- Subject: Re: [rfa] Fix software-watchpoint failures by adding epilogue detection
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