Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "pcarroll@codesourcery.com" <pcarroll@codesourcery.com>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: [PATCH] Modify Aarch64 prologue analyzer to accept 128-bit registers
Date: Mon, 13 Nov 2017 17:28:00 -0000	[thread overview]
Message-ID: <1816677702.1219332.1510594086497@mail.yahoo.com> (raw)
In-Reply-To: <1816677702.1219332.1510594086497.ref@mail.yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

GDB has a routine, aarch64_analyze_prologue, that looks through a function's prologue, to see how it affects the stack.
This was changed for Bugzilla #20682 to add support for recognizing the 'stp' instruction with floating-point registers.
That patch worked when 64-bit floating-point registers are used in a function prologue.
However, it is also possible to specify 128-bit floating-point registers with the 'stp' instruction.
My patch extends that function so it works for either 64-bit or 128-bit floating-point registers.
The patch takes care of tracking the appropriate memory locations that would be affected by the use of either size of register.

The assumption is that it is not important to know whether the register being saved is 64-bits or 128-bits in size, as long as the memory is tracked appropriately.
Instead, it is only important to know that a floating-point register (D) was being stored, rather than a normal register (X).
That behavior is unchanged.

2017-11-10  Paul Carroll  <pcarroll@codesourcery.com>

             * aarch64-tdep.c (aarch64_analyze_prologue):  Added support for
             128-bit registers with the 'stp' instruction.

[-- Attachment #2: aarch64_stp_patch --]
[-- Type: application/octet-stream, Size: 2729 bytes --]

diff -rup a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
--- a/gdb/aarch64-tdep.c	2017-11-10 12:15:43.129386073 -0800
+++ b/gdb/aarch64-tdep.c	2017-11-10 12:41:51.275661344 -0800
@@ -356,6 +356,7 @@ aarch64_analyze_prologue (struct gdbarch
 	  unsigned rt2;
 	  unsigned rn = inst.operands[2].addr.base_regno;
 	  int32_t imm = inst.operands[2].addr.offset.imm;
+	  CORE_ADDR reg_size = 8;
 
 	  gdb_assert (inst.operands[0].type == AARCH64_OPND_Rt
 		      || inst.operands[0].type == AARCH64_OPND_Ft);
@@ -364,29 +365,36 @@ aarch64_analyze_prologue (struct gdbarch
 	  gdb_assert (inst.operands[2].type == AARCH64_OPND_ADDR_SIMM7);
 	  gdb_assert (!inst.operands[2].addr.offset.is_reg);
 
+	  /* Take care of the case where 128-bit registers need to be stored */
+	  if (inst.operands[0].type == AARCH64_OPND_Ft &&
+	      inst.operands[0].qualifier == AARCH64_OPND_QLF_S_Q)
+	    reg_size = 16;
+
 	  /* If recording this store would invalidate the store area
 	     (perhaps because rn is not known) then we should abandon
 	     further prologue analysis.  */
 	  if (stack.store_would_trash (pv_add_constant (regs[rn], imm)))
 	    break;
 
-	  if (stack.store_would_trash (pv_add_constant (regs[rn], imm + 8)))
+	  if (stack.store_would_trash (pv_add_constant (regs[rn], 
+	  						imm + reg_size)))
 	    break;
 
 	  rt1 = inst.operands[0].reg.regno;
 	  rt2 = inst.operands[1].reg.regno;
 	  if (inst.operands[0].type == AARCH64_OPND_Ft)
 	    {
-	      /* Only bottom 64-bit of each V register (D register) need
-		 to be preserved.  */
-	      gdb_assert (inst.operands[0].qualifier == AARCH64_OPND_QLF_S_D);
+	      /* Only bottom 64-bit of each V register (D register) needs
+		 to be tracked.  */
+	      gdb_assert (inst.operands[0].qualifier == AARCH64_OPND_QLF_S_D ||
+	      		  inst.operands[0].qualifier == AARCH64_OPND_QLF_S_Q);
 	      rt1 += AARCH64_X_REGISTER_COUNT;
 	      rt2 += AARCH64_X_REGISTER_COUNT;
 	    }
 
-	  stack.store (pv_add_constant (regs[rn], imm), 8,
+	  stack.store (pv_add_constant (regs[rn], imm), reg_size,
 		       regs[rt1]);
-	  stack.store (pv_add_constant (regs[rn], imm + 8), 8,
+	  stack.store (pv_add_constant (regs[rn], imm + reg_size), reg_size,
 		       regs[rt2]);
 
 	  if (inst.operands[2].addr.writeback)
diff -rup a/gdb/ChangeLog b/gdb/ChangeLog
--- a/gdb/ChangeLog	2017-11-10 12:15:43.081386126 -0800
+++ b/gdb/ChangeLog	2017-11-10 12:36:31.052037951 -0800
@@ -1,3 +1,8 @@
+2017-11-10  Paul Carroll  <pcarroll@codesourcery.com>
+
+	* aarch64-tdep.c (aarch64_analyze_prologue): Added support for
+	128-bit registers with the 'stp' instruction.
+
 2017-11-09  Joel Brobecker  <brobecker@adacore.com>
 
 	* ada-lang.c: Fix some typos in the general command documenting

       reply	other threads:[~2017-11-13 17:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1816677702.1219332.1510594086497.ref@mail.yahoo.com>
2017-11-13 17:28 ` pcarroll [this message]
2017-11-13 17:32   ` Andrew Pinski
2017-11-14 14:01     ` Paul Carroll
2017-11-14 14:12       ` Luis Machado

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=1816677702.1219332.1510594086497@mail.yahoo.com \
    --to=pcarroll@codesourcery.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