From: jose.marchesi@oracle.com (Jose E. Marchesi)
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] add gdbarch_in_function_epilogue_p hook for sparc64
Date: Tue, 03 Dec 2013 11:58:00 -0000 [thread overview]
Message-ID: <878uw2w3en.fsf@oracle.com> (raw)
In-Reply-To: <87mwm8165p.fsf@oracle.com> (Jose E. Marchesi's message of "Thu, 17 Oct 2013 13:35:46 +0200")
ping
> Index: sparc-tdep.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/sparc-tdep.h,v
> retrieving revision 1.33
> diff -u -r1.33 sparc-tdep.h
> --- sparc-tdep.h 1 Jan 2013 06:32:51 -0000 1.33
> +++ sparc-tdep.h 16 Oct 2013 14:00:49 -0000
> @@ -193,6 +193,9 @@
> extern struct sparc_frame_cache *
> sparc32_frame_cache (struct frame_info *this_frame, void **this_cache);
>
> +extern int
> +sparc_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc);
Not really a review, but the function name should not start on column 0
for prototypes.
Thanks for noticing out.
Amended patch below.
2013-10-16 Jose E. Marchesi <jose.marchesi@oracle.com>
* 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.
Index: sparc-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparc-tdep.c,v
retrieving revision 1.233
diff -u -r1.233 sparc-tdep.c
--- sparc-tdep.c 24 Jun 2013 22:18:32 -0000 1.233
+++ sparc-tdep.c 16 Oct 2013 14:00:49 -0000
@@ -88,6 +88,8 @@
#define X_DISP19(i) ((((i) & 0x7ffff) ^ 0x40000) - 0x40000)
#define X_DISP10(i) ((((((i) >> 11) && 0x300) | (((i) >> 5) & 0xff)) ^ 0x200) - 0x200)
#define X_SIMM13(i) ((((i) & 0x1fff) ^ 0x1000) - 0x1000)
+/* Macros to identify some instructions. */
+#define X_RETTURN(i) ((X_OP (i) == 0x2) && (X_OP3 (i) == 0x39))
/* Fetch the instruction at PC. Instructions are always big-endian
even if the processor operates in little-endian mode. */
@@ -421,6 +434,29 @@
regcache_raw_write (regcache, regnum + 1, buf + 4);
}
\f
+/* 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)
+{
+ /* 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 transfer 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);
+}
+\f
static CORE_ADDR
sparc32_frame_align (struct gdbarch *gdbarch, CORE_ADDR address)
Index: sparc-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/sparc-tdep.h,v
retrieving revision 1.33
diff -u -r1.33 sparc-tdep.h
--- sparc-tdep.h 1 Jan 2013 06:32:51 -0000 1.33
+++ sparc-tdep.h 16 Oct 2013 14:00:49 -0000
@@ -193,6 +193,9 @@
extern struct sparc_frame_cache *
sparc32_frame_cache (struct frame_info *this_frame, void **this_cache);
+extern int
+ sparc_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc);
+
\f
extern int sparc_software_single_step (struct frame_info *frame);
Index: sparc64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparc64-tdep.c,v
retrieving revision 1.62
diff -u -r1.62 sparc64-tdep.c
--- sparc64-tdep.c 1 Jan 2013 06:32:51 -0000 1.62
+++ sparc64-tdep.c 16 Oct 2013 14:00:49 -0000
@@ -1197,6 +1198,9 @@
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);
+
/* Hook in the DWARF CFI frame unwinder. */
dwarf2_frame_set_init_reg (gdbarch, sparc64_dwarf2_frame_init_reg);
/* FIXME: kettenis/20050423: Don't enable the unwinder until the
next prev parent reply other threads:[~2013-12-03 11:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-16 14:16 Jose E. Marchesi
2013-10-16 20:53 ` Sergio Durigan Junior
2013-10-17 11:33 ` Jose E. Marchesi
2013-12-03 11:58 ` Jose E. Marchesi [this message]
2013-12-03 19:03 ` Pedro Alves
2013-12-04 10:07 ` Jose E. Marchesi
2013-12-04 12:15 ` Pedro Alves
2013-12-04 12:22 ` Jose E. Marchesi
2014-01-29 15:31 ` Jose E. Marchesi
2014-02-06 14:24 ` Jose E. Marchesi
2014-02-08 3:01 ` Joel Brobecker
2014-02-10 12:37 ` Jose E. Marchesi
2014-02-10 15:08 ` Mark Kettenis
2014-02-10 15:23 ` Jose E. Marchesi
2013-12-04 17:02 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878uw2w3en.fsf@oracle.com \
--to=jose.marchesi@oracle.com \
--cc=gdb-patches@sourceware.org \
--cc=sergiodj@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox