From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4456 invoked by alias); 28 Sep 2010 15:15:44 -0000 Received: (qmail 4427 invoked by uid 22791); 28 Sep 2010 15:15:42 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Sep 2010 15:15:34 +0000 Received: (qmail 28279 invoked from network); 28 Sep 2010 15:15:32 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Sep 2010 15:15:32 -0000 Date: Tue, 28 Sep 2010 20:23:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org, rearnsha@arm.com Subject: Re: [rfa] Fix software-watchpoint failures by adding epilogue detection Message-ID: <20100928151529.GG6886@caradoc.them.org> References: <201009231300.o8ND0YqF028161@d12av02.megacenter.de.ibm.com> <201009241239.o8OCd52U013473@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201009241239.o8OCd52U013473@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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 X-SW-Source: 2010-09/txt/msg00472.txt.bz2 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