From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4794 invoked by alias); 27 Aug 2014 10:59:15 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 4782 invoked by uid 89); 27 Aug 2014 10:59:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 27 Aug 2014 10:59:13 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7RAxArx012362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Aug 2014 06:59:11 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7RAx9Hk031165; Wed, 27 Aug 2014 06:59:10 -0400 Message-ID: <53FDB9FD.60900@redhat.com> Date: Wed, 27 Aug 2014 10:59:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH] arm software watchpoint: return to epilogue References: <1407295090-17296-1-git-send-email-yao@codesourcery.com> In-Reply-To: <1407295090-17296-1-git-send-email-yao@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-08/txt/msg00563.txt.bz2 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