From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18605 invoked by alias); 8 Feb 2014 03:01:52 -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 18574 invoked by uid 89); 8 Feb 2014 03:01:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 08 Feb 2014 03:01:49 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 01989116528; Fri, 7 Feb 2014 22:01:48 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3p+DeAb70Yq4; Fri, 7 Feb 2014 22:01:47 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 804AD116523; Fri, 7 Feb 2014 22:01:47 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 45AE1E0BA8; Sat, 8 Feb 2014 07:01:46 +0400 (RET) Date: Sat, 08 Feb 2014 03:01:00 -0000 From: Joel Brobecker To: "Jose E. Marchesi" Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH] add gdbarch_in_function_epilogue_p hook for sparc64 Message-ID: <20140208030146.GK5485@adacore.com> References: <87mwm9b8pr.fsf@oracle.com> <529E2ADD.6020409@redhat.com> <8738m9j5de.fsf@oracle.com> <529F1CE0.2060000@redhat.com> <87y540iz29.fsf@oracle.com> <87ppnau7ho.fsf@oracle.com> <87ppn0uxid.fsf@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ppn0uxid.fsf@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-02/txt/msg00234.txt.bz2 Jose, (a small request to avoid the extra-large indentation when pinging - thank you!) > 2013-10-16 Jose E. Marchesi > > * sparc-tdep.c (sparc_in_function_epilogue_p): New function. > (X_RETTURN): New macro. > * sparc-tdep.h: sparc_in_function_epilogue_p prototype. > > * sparc64-tdep.c (sparc64_init_abi): Hook > sparc_in_function_epilogue_p. Regarding testing this function on sparc32: Can you tell us which testcase in our testsuite this patch fixes? Although I am allowed to run the testsuite, I can still run individual testcases by hand (if not too complex, of course). Otherwise, would you have a small reproducer I could use to test on sparc32? Comments about the patch below. > +/* Macros to identify some instructions. */ > +#define X_RETTURN(i) ((X_OP (i) == 0x2) && (X_OP3 (i) == 0x39)) Can your comment say a little more precisely what instruction it identifies? I think the parens around the equality operators are superfluous and should be removed. > +/* Return true if we are in a function's epilogue, i.e. after an > + instruction that destroyed a function's stack frame. */ > + > +int > +sparc_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc) > +{ The general principle for function meant to be used as gdbarch callbacks is just to say: /* Implement "in_function_epilogue_p". */ That way, if we ever change the function's prototype, we don't have to update the documentation everywhere. This callback should only be documented in gdbarch.sh (and repeated in gdbarch.h, which is generated from gdbarch.sh). In your case, since there are 32bit and 64bit versions, you can add something like, for instance: This implementation works on both sparc32 and sparc64. > + /* This function must return true if we are one instruction after an > + instruction that destroyed the stack frame of the current > + function. The SPARC instructions used to restore the callers > + stack frame are RESTORE and RETURN/RETT. > + > + Of these RETURN/RETT is a branch instruction and thus we return > + true if we are in its delay slot. > + > + RESTORE is almost always found in the delay slot of a branch > + instruction that transfers control to the caller, such as JMPL. > + Thus the next instruction is in the caller frame and we don't > + need to do anything about it. */ > + > + unsigned int insn = sparc_fetch_instruction (pc - 4); > + return X_RETTURN (insn); Small quirk of the GDB Coding Style: We require an empty line between local variable declarations and the statements after. Also, I notice there are trailing spaces. > set_gdbarch_skip_prologue (gdbarch, sparc64_skip_prologue); > > + /* Detect whether PC is in function epilogue. */ > + set_gdbarch_in_function_epilogue_p (gdbarch, sparc_in_function_epilogue_p); > + I would normally not comment on this, but since I've made other comments, I'll ask that the comment be revmoved, and that you avoid the empty line between the call to set_gdbarch_skip_prologue just above and the call to set_gdbarch_in_function_epilogue_p that you are adding. I am asking because the comment in this case is only repeating the obvious without explaining why it's necessary. So it feels superfluous and better without. Thank you, -- Joel