From: jose.marchesi@oracle.com (Jose E. Marchesi)
To: gdb-patches@sourceware.org
Subject: [PATCH] add gdbarch_in_function_epilogue_p hook for sparc64
Date: Wed, 16 Oct 2013 14:16:00 -0000 [thread overview]
Message-ID: <87mwm9b8pr.fsf@oracle.com> (raw)
Hi.
watchpoint_update and watchpoint_cond avoid checking for watchpoints
when we are located at a function epilogue in the current frame. This
is done in order to avoid using corrupted local registers and unwinding
a corrupted/destroyed stack.
The code determining whether we are in a function epilogue is provided
by the backends via the gdbarch_in_function_epilogue_p hook. The patch
below adds such a hook for sparc.
Note that despite sparc_in_function_epilogue_p must work on both sparc32
and sparc64 the patch only installs the hook on sparc64 targets. This
is because I can't test it in sparc32.
This patch makes all the tests on watch-cond.exp to pass on
sparc64-unknown-linux-gnu.
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 reply other threads:[~2013-10-16 14:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-16 14:16 Jose E. Marchesi [this message]
2013-10-16 20:53 ` Sergio Durigan Junior
2013-10-17 11:33 ` Jose E. Marchesi
2013-12-03 11:58 ` Jose E. Marchesi
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=87mwm9b8pr.fsf@oracle.com \
--to=jose.marchesi@oracle.com \
--cc=gdb-patches@sourceware.org \
/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