Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: jose.marchesi@oracle.com (Jose E. Marchesi)
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] add gdbarch_in_function_epilogue_p hook for sparc64
Date: Wed, 04 Dec 2013 12:22:00 -0000	[thread overview]
Message-ID: <87y540iz29.fsf@oracle.com> (raw)
In-Reply-To: <529F1CE0.2060000@redhat.com> (Pedro Alves's message of "Wed, 04	Dec 2013 12:15:28 +0000")


    >     +     RESTORE is almost always found in the delay slot of a branch
    >     +     instruction that transfer control to the caller, such as JMPL.
    
    "transfers".

Typo amended 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 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);
+}
+\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


  reply	other threads:[~2013-12-04 12:22 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
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 [this message]
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=87y540iz29.fsf@oracle.com \
    --to=jose.marchesi@oracle.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@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