This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] arm software watchpoint: return to epilogue
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Wed, 27 Aug 2014 11:59:09 +0100
- Subject: Re: [PATCH] arm software watchpoint: return to epilogue
- Authentication-results: sourceware.org; auth=none
- References: <1407295090-17296-1-git-send-email-yao at codesourcery dot com>
On 08/06/2014 04:18 AM, Yao Qi wrote:
> It doesn't work in this case, because program returns from func's
> epilogue back to jumper's epilogue [2], GDB thinks the program is
> still within the epilogue, but in fact it goes to a different one.
> When PC points at [2], the sp-restore instruction is to be
> executed, so the stack frame isn't destroyed yet and we can still
> use the frame mechanism reliably.
> What this patch does is to restrict the epilogue matching that let
> GDB think the first SP restore instruction isn't part of the epilogue,
> and fall back to use frame mechanism.
This gdbarch hook's name is a bit misleading -- your comment above kind
of makes it sound like the patch is doing some kind of target specific
hack, while this is exactly how the gdbarch hook is specified:
# A target might have problems with watchpoints as soon as the stack
# frame of the current function has been destroyed. This mostly happens
# as the first action in a funtion's epilogue. in_function_epilogue_p()
# is defined to return a non-zero value if either the given addr is one
^^^^^^
# instruction after the stack destroying instruction up to the trailing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# return instruction or if we can figure out that the stack frame has
# already been invalidated regardless of the value of addr. Targets
# which don't suffer from that problem could just let this functionality
# untouched.
m:int:in_function_epilogue_p:CORE_ADDR addr:addr:0:generic_in_function_epilogue_p::0
> The patch is tested in arm-none-eabi and arm-none-linux-gnueabi with
> various multilibs. OK to apply?
This is OK with Will's comment addressed.
Thanks,
Pedro Alves