[PATCH v2 0/3] Small step in supporting AVX instructions

[PATCH v2 0/3] Small step in supporting AVX instructions

[Guinevere Larsen]

This patch series is the first, very small, step in supporting AVX and
AVX2 instructions for the record-full target. It is important that we
support it since glibc has been using avx instructions for a long time
(at least fedora 21), so depending on which functions an inferior uses,
they might be very inconvenienced.

Patch 1 adds capability to identify the VEX prefix, but no instruction
support. Patches 2 and 3 add support for a total of 10 instructions,
which covers around 5% of all AVX instructions used by system libraries
in my fedora 39 box.

While this support is extremely minimal, I figured I could propose the
patch series early so it was open for others with more free time could
help contributing to this :)

---
Changes for v2:
* stopped using "error" when finding incorrect encoding in vmov
  instructions, as suggested by Tom Tromey.
* Changed i386-avx-reverse test, to stop failing with clang.
* Changed the KFAIL in gdb.reverse/step-precsave, so we don't get new
  FAILs while AVX support is incomplete.

Guinevere Larsen (3):
  gdb: Start supporting AVX instruction
  gdb/record: add support to vmovd and vmovq instructions
  gdb/record: add support to AVX unpack instructions

 gdb/amd64-tdep.c                              |   3 +-
 gdb/i386-tdep.c                               | 173 ++++++++++++++-
 gdb/i386-tdep.h                               |   2 +
 gdb/testsuite/gdb.reverse/i386-avx-reverse.c  | 138 ++++++++++++
 .../gdb.reverse/i386-avx-reverse.exp          | 203 ++++++++++++++++++
 gdb/testsuite/gdb.reverse/step-precsave.exp   |   4 +-
 6 files changed, 518 insertions(+), 5 deletions(-)
 create mode 100644 gdb/testsuite/gdb.reverse/i386-avx-reverse.c
 create mode 100644 gdb/testsuite/gdb.reverse/i386-avx-reverse.exp

-- 
2.45.1

[PATCH v2 1/3] gdb: Start supporting AVX instruction

[Guinevere Larsen]

This patch introduces the information needed to properly identify the
VEX prefix, used to signal an AVX and AVX2 instruction, and introduces
a helper function to handle all AVX instruction, instead of adding to
the 3000 line long recording function.

The new helper also handles unsupported instructions so that the largest
part of the i386_process_record doesn't have to be shifted by 2 spaces,
which made an unreadably big patch file.

The only expected difference to the end user added by this patch is a
small change to the unsupported message. This patch also updates the
test gdb.reverse/step-precsave.exp, by recognizing the new output.

As a note for the future, we don't handle xmm16-31 and ymm16-31 because
those require the EVEX prefix, meaning avx512 support.
---
 gdb/amd64-tdep.c                            |  3 +-
 gdb/i386-tdep.c                             | 91 ++++++++++++++++++++-
 gdb/i386-tdep.h                             |  2 +
 gdb/testsuite/gdb.reverse/step-precsave.exp |  2 +-
 4 files changed, 94 insertions(+), 4 deletions(-)

diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c
index df6b882a3fb..27d6e20f90c 100644
--- a/gdb/amd64-tdep.c
+++ b/gdb/amd64-tdep.c
@@ -3134,7 +3134,8 @@ static const int amd64_record_regmap[] =
   AMD64_R8_REGNUM, AMD64_R9_REGNUM, AMD64_R10_REGNUM, AMD64_R11_REGNUM,
   AMD64_R12_REGNUM, AMD64_R13_REGNUM, AMD64_R14_REGNUM, AMD64_R15_REGNUM,
   AMD64_RIP_REGNUM, AMD64_EFLAGS_REGNUM, AMD64_CS_REGNUM, AMD64_SS_REGNUM,
-  AMD64_DS_REGNUM, AMD64_ES_REGNUM, AMD64_FS_REGNUM, AMD64_GS_REGNUM
+  AMD64_DS_REGNUM, AMD64_ES_REGNUM, AMD64_FS_REGNUM, AMD64_GS_REGNUM,
+  AMD64_XMM0_REGNUM, AMD64_YMM0H_REGNUM
 };
 
 /* Implement the "in_indirect_branch_thunk" gdbarch function.  */
diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index f1f909e1616..ff98818d271 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -4637,6 +4637,12 @@ struct i386_record_s
   int rip_offset;
   int popl_esp_hack;
   const int *regmap;
+
+  /* These are used by VEX and XOP prefixes.  */
+  uint8_t map_select;
+  uint8_t vvvv;
+  uint8_t pp;
+  uint8_t l;
 };
 
 /* Parse the "modrm" part of the memory address irp->addr points at.
@@ -4975,6 +4981,31 @@ static int i386_record_floats (struct gdbarch *gdbarch,
   return 0;
 }
 
+/* i386_process_record helper to deal with instructions that start
+   with VEX prefix.  */
+
+static int
+i386_record_vex (struct i386_record_s *ir, uint8_t vex_w, uint8_t vex_r,
+		 int opcode, struct gdbarch *gdbarch)
+{
+  switch (opcode)
+    {
+    default:
+      gdb_printf (gdb_stderr,
+		  _("Process record does not support VEX instruction 0x%02x "
+		    "at address %s.\n"),
+		  (unsigned int) (opcode),
+		  paddress (gdbarch, ir->orig_addr));
+      return -1;
+    }
+
+  record_full_arch_list_add_reg (ir->regcache, ir->regmap[X86_RECORD_REIP_REGNUM]);
+  if (record_full_arch_list_add_end ())
+    return -1;
+
+  return 0;
+}
+
 /* Parse the current instruction, and record the values of the
    registers and memory that will be changed by the current
    instruction.  Returns -1 if something goes wrong, 0 otherwise.  */
@@ -4997,6 +5028,7 @@ i386_process_record (struct gdbarch *gdbarch, struct regcache *regcache,
   i386_gdbarch_tdep *tdep = gdbarch_tdep<i386_gdbarch_tdep> (gdbarch);
   uint8_t rex_w = -1;
   uint8_t rex_r = 0;
+  bool vex_prefix = false;
 
   memset (&ir, 0, sizeof (struct i386_record_s));
   ir.regcache = regcache;
@@ -5082,6 +5114,53 @@ i386_process_record (struct gdbarch *gdbarch, struct regcache *regcache,
 	  else					/* 32 bit target */
 	    goto out_prefixes;
 	  break;
+	case 0xc4:	/* 3-byte VEX prefixes (for AVX/AVX2 instructions).  */
+	  {
+	    /* The first byte just identifies the VEX prefix.  Data is stored
+	       on the following 2 bytes.  */
+	    uint8_t byte;
+	    if (record_read_memory (gdbarch, ir.addr, &byte, 1))
+	      return -1;
+	    ir.addr++;
+
+	    rex_r = !((byte >> 7) & 0x1);
+	    ir.rex_x = !((byte >> 6) & 0x1);
+	    ir.rex_b = !((byte >> 5) & 0x1);
+	    ir.map_select = byte & 0x1f;
+	    /* Collect the last byte of the prefix.  */
+	    if (record_read_memory (gdbarch, ir.addr, &byte, 1))
+	      return -1;
+	    ir.addr++;
+	    rex_w = (byte >> 7) & 0x1;
+	    ir.vvvv = (~(byte >> 3) & 0xf);
+	    ir.l = (byte >> 2) & 0x1;
+	    ir.pp = byte & 0x3;
+	    vex_prefix = true;
+
+	    break;
+	  }
+	case 0xc5:	/* 2-byte VEX prefix for AVX/AVX2 instructions.  */
+	  {
+	    /* The first byte just identifies the VEX prefix.  Data is stored
+	       on the following 2 bytes.  */
+	    uint8_t byte;
+	    if (record_read_memory (gdbarch, ir.addr, &byte, 1))
+	      return -1;
+	    ir.addr++;
+
+	    /* On the 2-byte versions, these are pre-defined.  */
+	    ir.rex_x = 0;
+	    ir.rex_b = 0;
+	    rex_w = 0;
+	    ir.map_select = 1;
+
+	    rex_r = !((byte >> 7) & 0x1);
+	    ir.vvvv = (~(byte >> 3) & 0xf);
+	    ir.l = (byte >> 2) & 0x1;
+	    ir.pp = byte & 0x3;
+	    vex_prefix = true;
+	    break;
+	  }
 	default:
 	  goto out_prefixes;
 	  break;
@@ -5104,6 +5183,12 @@ i386_process_record (struct gdbarch *gdbarch, struct regcache *regcache,
 
   /* Now check op code.  */
   opcode = (uint32_t) opcode8;
+  if (vex_prefix)
+    {
+      /* If we found the VEX prefix, i386 will either record or warn that
+	 the instruction isn't supported, so we can return the VEX result.  */
+      return i386_record_vex (&ir, rex_w, rex_r, opcode, gdbarch);
+    }
  reswitch:
   switch (opcode)
     {
@@ -8088,9 +8173,11 @@ static const int i386_record_regmap[] =
 {
   I386_EAX_REGNUM, I386_ECX_REGNUM, I386_EDX_REGNUM, I386_EBX_REGNUM,
   I386_ESP_REGNUM, I386_EBP_REGNUM, I386_ESI_REGNUM, I386_EDI_REGNUM,
-  0, 0, 0, 0, 0, 0, 0, 0,
+  0, 0, 0, 0,
+  0, 0, 0, 0,
   I386_EIP_REGNUM, I386_EFLAGS_REGNUM, I386_CS_REGNUM, I386_SS_REGNUM,
-  I386_DS_REGNUM, I386_ES_REGNUM, I386_FS_REGNUM, I386_GS_REGNUM
+  I386_DS_REGNUM, I386_ES_REGNUM, I386_FS_REGNUM, I386_GS_REGNUM,
+  /* xmm0_regnum */ 0, I386_YMM0H_REGNUM
 };
 
 /* Check that the given address appears suitable for a fast
diff --git a/gdb/i386-tdep.h b/gdb/i386-tdep.h
index a85e0a984a0..1f21f8de06c 100644
--- a/gdb/i386-tdep.h
+++ b/gdb/i386-tdep.h
@@ -339,6 +339,8 @@ enum record_i386_regnum
   X86_RECORD_ES_REGNUM,
   X86_RECORD_FS_REGNUM,
   X86_RECORD_GS_REGNUM,
+  X86_RECORD_XMM0_REGNUM,
+  X86_RECORD_YMM0H_REGNUM,
 };
 
 #define I386_NUM_GREGS	16
diff --git a/gdb/testsuite/gdb.reverse/step-precsave.exp b/gdb/testsuite/gdb.reverse/step-precsave.exp
index d9377635dcf..47d494a5d73 100644
--- a/gdb/testsuite/gdb.reverse/step-precsave.exp
+++ b/gdb/testsuite/gdb.reverse/step-precsave.exp
@@ -46,7 +46,7 @@ with_timeout_factor 20 {
 	-re -wrap "Breakpoint .* end of main .*" {
 	    pass $gdb_test_name
 	}
-	-re -wrap "Process record does not support instruction 0xc5 at.*" {
+	-re -wrap "Process record does not support VEX instruction.*" {
 	    kfail "record/23188" $gdb_test_name
 	}
 	-re -wrap "Process record does not support instruction 0xfae64 at.*" {
-- 
2.45.1

[PATCH v2 2/3] gdb/record: add support to vmovd and vmovq instructions

[Guinevere Larsen]

This commit adds support to the x86_64 AVX instructions vmovd and vmovq.
The programmers manuals for Intel and AMD describe these 2 instructions
as being almost the same, but my local testing, using gcc 13.2 on Fedora
39, showed several differences and inconsistencies.

The instruction is supposed to always use the 3-byte VEX prefix, but I
could only find 2-byte versions. The instructions aren't differentiated
by the VEX.w bit, but by opcodes and VEX.pp.

This patch adds a test with many different uses for both vmovd and
vmovq. It also updates the test gdb.reverse/step-precsave.exp to opint
to the generic "missing avx support" bug open in the bugtracker (17346),
instead of pointing to one that specifically calls out to vmovd
instructions.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23188
---
 gdb/i386-tdep.c                               |  70 +++++++
 gdb/testsuite/gdb.reverse/i386-avx-reverse.c  |  95 ++++++++++
 .../gdb.reverse/i386-avx-reverse.exp          | 178 ++++++++++++++++++
 gdb/testsuite/gdb.reverse/step-precsave.exp   |   2 +-
 4 files changed, 344 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.reverse/i386-avx-reverse.c
 create mode 100644 gdb/testsuite/gdb.reverse/i386-avx-reverse.exp

diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index ff98818d271..b11748be45f 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -4990,6 +4990,76 @@ i386_record_vex (struct i386_record_s *ir, uint8_t vex_w, uint8_t vex_r,
 {
   switch (opcode)
     {
+    case 0x6e:	/* VMOVD XMM, reg/mem  */
+      /* This is moving from a regular register or memory region into an
+	 XMM register. */
+      i386_record_modrm (ir);
+      /* ModR/M only has the 3 least significant bits of the destination
+	 register, the last one is indicated by VEX.R (stored inverted).  */
+      record_full_arch_list_add_reg (ir->regcache,
+				     ir->regmap[X86_RECORD_XMM0_REGNUM]
+				       + ir->reg + vex_r * 8);
+      break;
+    case 0x7e:	/* VMOV(D/Q)  */
+      i386_record_modrm (ir);
+      /* Both the intel and AMD manual are wrong about this.  According to
+	 it, the only difference between vmovq and vmovd should be the rex_w
+	 bit, but in empirical testing, it seems that they share this opcode,
+	 and the way to differentiate it here is looking at VEX.PP.  */
+      if (ir->pp == 2)
+	{
+	  /* This is vmovq moving from a regular register or memory
+	     into an XMM register.  As above, VEX.R is the final bit for
+	     destination register.  */
+	  record_full_arch_list_add_reg (ir->regcache,
+					 ir->regmap[X86_RECORD_XMM0_REGNUM]
+					 + ir->reg + vex_r * 8);
+	}
+      else if (ir->pp == 1)
+	{
+	  /* This is the vmovd version that stores into a regular register
+	     or memory region.  */
+	  /* If ModRM.mod is 11 we are saving into a register.  */
+	  if (ir->mod == 3)
+	    record_full_arch_list_add_reg (ir->regcache, ir->regmap[ir->rm]);
+	  else
+	    {
+	      /* Calculate the size of memory that will be modified
+		 and store it in the form of 1 << ir->ot, since that
+		 is how the function uses it.  In theory, VEX.W is supposed
+		 to indicate the size of the memory. In practice, I only
+		 ever seen it set to 0, and for 16 bytes, 0xD6 opcode
+		 is used.  */
+	      if (vex_w)
+		ir->ot = 4;
+	      else
+		ir->ot = 3;
+
+	      i386_record_lea_modrm (ir);
+	    }
+	}
+      else
+	{
+	  gdb_printf ("Unrecognized VEX.PP value %d at address %s.",
+		      ir->pp, paddress(gdbarch, ir->orig_addr));
+	  return -1;
+	}
+      break;
+    case 0xd6: /* VMOVQ reg/mem XMM  */
+      i386_record_modrm (ir);
+      /* This is the vmovq version that stores into a regular register
+	 or memory region.  */
+      /* If ModRM.mod is 11 we are saving into a register.  */
+      if (ir->mod == 3)
+	record_full_arch_list_add_reg (ir->regcache, ir->regmap[ir->rm]);
+      else
+	{
+	  /* We know that this operation is always 64 bits.  */
+	  ir->ot = 4;
+	  i386_record_lea_modrm (ir);
+	}
+      break;
+
     default:
       gdb_printf (gdb_stderr,
 		  _("Process record does not support VEX instruction 0x%02x "
diff --git a/gdb/testsuite/gdb.reverse/i386-avx-reverse.c b/gdb/testsuite/gdb.reverse/i386-avx-reverse.c
new file mode 100644
index 00000000000..eeda8b67582
--- /dev/null
+++ b/gdb/testsuite/gdb.reverse/i386-avx-reverse.c
@@ -0,0 +1,95 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2023 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+/* Architecture tests for intel i386 platform.  */
+
+#include <stdlib.h>
+
+char global_buf0[] = {0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
+		      0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f};
+char global_buf1[] = {0, 0, 0, 0, 0, 0, 0, 0,
+		      0, 0, 0, 0, 0, 0, 0, 0};
+char *dyn_buf0;
+char *dyn_buf1;
+
+int
+vmov_test ()
+{
+  char buf0[] = {0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
+		 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f};
+  char buf1[] = {0, 0, 0, 0, 0, 0, 0, 0,
+		 0, 0, 0, 0, 0, 0, 0, 0};
+
+  /*start vmov_test.  */
+
+  /* Operations on registers.  */
+  asm volatile ("mov $0, %rcx");
+  asm volatile ("mov $0xbeef, %rax");
+  asm volatile ("vmovd %rax, %xmm0");
+  asm volatile ("vmovd %xmm0, %rcx");
+
+  /* Operations based on local buffers.  */
+  asm volatile ("vmovd %0, %%xmm0": : "m"(buf0));
+  asm volatile ("vmovd %%xmm0, %0": "=m"(buf1));
+  asm volatile ("vmovq %0, %%xmm0": : "m"(buf0));
+  asm volatile ("vmovq %%xmm0, %0": "=m"(buf1));
+
+  /* Operations based on global buffers.  */
+  asm volatile ("vmovd %0, %%xmm0": : "m"(global_buf0));
+  asm volatile ("vmovd %%xmm0, %0": "=m"(global_buf1));
+  asm volatile ("vmovq %0, %%xmm0": : "m"(global_buf0));
+  asm volatile ("vmovq %%xmm0, %0": "=m"(global_buf1));
+
+  /* Operations based on dynamic buffers.  */
+  asm volatile ("vmovd %0, %%xmm0": : "m"(*dyn_buf0));
+  asm volatile ("vmovd %%xmm0, %0": "=m"(*dyn_buf1));
+  asm volatile ("vmovq %0, %%xmm0": : "m"(*dyn_buf0));
+  asm volatile ("vmovq %%xmm0, %0": "=m"(*dyn_buf1));
+
+  /* Reset all relevant buffers. */
+  asm volatile ("vmovq %%xmm15, %0": "=m" (buf1));
+  asm volatile ("vmovq %%xmm15, %0": "=m" (global_buf1));
+  asm volatile ("vmovq %%xmm15, %0": "=m" (*dyn_buf1));
+
+  /* Quick test for a different xmm register.  */
+  asm volatile ("vmovd %0, %%xmm15": "=m" (buf0));
+  asm volatile ("vmovd %0, %%xmm15": "=m" (buf1));
+  asm volatile ("vmovq %0, %%xmm15": "=m" (buf0));
+  asm volatile ("vmovq %0, %%xmm15": "=m" (buf1));
+
+  /* We have a return statement to deal with
+     epilogue in different compilers.  */
+  return 0; /* end vmov_test */
+}
+
+int
+main ()
+{
+  dyn_buf0 = (char *) malloc(sizeof(char) * 16);
+  dyn_buf1 = (char *) malloc(sizeof(char) * 16);
+  for (int i =0; i < 16; i++)
+    {
+      dyn_buf0[i] = 0x20 + i;
+      dyn_buf1[i] = 0;
+    }
+  /* Zero relevant xmm registers, se we know what to look for.  */
+  asm volatile ("vmovq %0, %%xmm0": : "m" (global_buf1));
+  asm volatile ("vmovq %0, %%xmm15": : "m" (global_buf1));
+
+  vmov_test ();
+  return 0;	/* end of main */
+}
diff --git a/gdb/testsuite/gdb.reverse/i386-avx-reverse.exp b/gdb/testsuite/gdb.reverse/i386-avx-reverse.exp
new file mode 100644
index 00000000000..e176428bb10
--- /dev/null
+++ b/gdb/testsuite/gdb.reverse/i386-avx-reverse.exp
@@ -0,0 +1,178 @@
+# Copyright 2009-2023 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# This file is part of the gdb testsuite.
+
+#
+# This test tests some i386 general instructions for reverse execution.
+#
+
+require supports_reverse
+
+if {![istarget "*86*-*linux*"]} {
+    verbose "Skipping i386 reverse tests."
+    return
+}
+
+standard_testfile
+
+# some targets have leading underscores on assembly symbols.
+set additional_flags [gdb_target_symbol_prefix_flags]
+
+if {[prepare_for_testing "failed to prepare" $testfile $srcfile \
+	 [list debug $additional_flags]]} {
+    return -1
+}
+
+# Shorthand to test reversing through one instruction and
+# testing if a register has the expected value.
+# Prefix, if included, should end with a colon and space.
+
+proc test_one_register {insn register value {prefix ""}} {
+    gdb_test "reverse-step" "$insn.*" \
+	"${prefix}reverse-step from $insn to test register $register"
+
+    gdb_test "info register $register" \
+	"$register.*uint128 = $value.*" \
+	"${prefix}verify $register before $insn"
+}
+
+# Shorthand to test reversing through one instruction and
+# testing if a variable has the expected value.
+# Prefix, if used, should end with a colon and space.
+
+proc test_one_memory {insn mem value {dynamic false} {prefix ""}} {
+    gdb_test "reverse-step" "$insn.*" \
+	"${prefix}reverse-step from $insn to test memory $mem"
+
+    # For the dynamic buffer, we have to cast and dereference the pointer
+    set cast ""
+    if {$dynamic == true} {
+	set cast {(char [16]) *}
+    }
+
+    gdb_test "p/x $cast$mem" \
+	".*$value.*" \
+	"${prefix}verify $mem before $insn"
+
+}
+
+# Record the execution for the whole function, and stop at its end
+# to check if we can correctly reconstruct the state.
+# In the source code, the function must be FUNCTION_test, and
+# at the end, it must have a comment in the form:
+# /* end FUNCTION_test */
+# Returns true if the full function could be recorded, false otherwise.
+proc record_full_function {function} {
+    set end [gdb_get_line_number "end ${function}_test "]
+    set start [gdb_get_line_number "start ${function}_test"]
+    gdb_breakpoint $start temporary
+    gdb_breakpoint $end temporary
+    gdb_continue_to_breakpoint "start ${function}_test"
+
+    if [supports_process_record] {
+	# Activate process record/replay.
+	gdb_test_no_output "record" "${function}: turn on process record"
+    }
+
+    # We return early in gdb_test_multiple because the rest of the
+    # function is aborting recording and cleaning up to put us back in
+    # a known location.
+    gdb_test_multiple "continue" "continue to end of ${function}_test" {
+	-re " end ${function}_test .*\r\n$::gdb_prompt $" {
+	    pass $gdb_test_name
+	    return true
+	}
+	-re " Illegal instruction.*\r\n$::gdb_prompt $" {
+	    fail $gdb_test_name
+	}
+	-re "Process record does not support VEX instruction.*" {
+	    fail $gdb_test_name
+	}
+    }
+
+    gdb_test "record stop" "Process record is stopped.*" \
+	"delete failed record history"
+    # If we didn't exit early, the temporary breakpoint at the end of
+    # the function hasn't been hit yet, so we can just continue.
+    gdb_continue_to_breakpoint "end ${function}_test" ".*end ${function}_test.*"
+
+    return false
+}
+
+runto_main
+
+global hex
+global decimal
+
+# Record all the execution for vmov tests first.
+
+if {[record_full_function "vmov"] == true} {
+    # Now execute backwards, checking all instructions.
+    # First we test all instructions handling global buffers.
+
+    test_one_register "vmovq" "xmm15" "0x3736353433323130" "reg_reset: "
+    test_one_register "vmovq" "xmm15" "0x0"
+    test_one_register "vmovd" "xmm15" "0x33323130" "reg_reset: "
+    test_one_register "vmovd" "xmm15" "0x0"
+
+    with_test_prefix buffer_reset {
+	test_one_memory "vmovq" "dyn_buf1" \
+	    "0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x0" true
+	test_one_memory "vmovq" "global_buf1" \
+	    "0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x0"
+	test_one_memory "vmovq" "buf1" \
+	    "0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x0"
+    }
+
+    with_test_prefix dynamic_buffers {
+	test_one_memory "vmovq" "dyn_buf1" "0x20, 0x21, 0x22, 0x23, 0x0" true
+	test_one_register "vmovq" "xmm0" "0x23222120"
+	test_one_memory "vmovd" "dyn_buf1" "0x0 .repeats 16 times" true
+	test_one_register "vmovd" "xmm0" "0x1716151413121110"
+    }
+
+    with_test_prefix global_buffers {
+	test_one_memory "vmovq" "global_buf1" "0x10, 0x11, 0x12, 0x13, 0x0"
+	test_one_register "vmovq" "xmm0" "0x13121110"
+	test_one_memory "vmovd" "global_buf1" "0x0 .repeats 16 times"
+	test_one_register "vmovd" "xmm0" "0x3736353433323130"
+    }
+
+    with_test_prefix local_buffers {
+	test_one_memory "vmovq" "buf1" "0x30, 0x31, 0x32, 0x33, 0x0"
+	test_one_register "vmovq" "xmm0" "0x33323130"
+	test_one_memory "vmovd" "buf1" "0x0 .repeats 16 times"
+	test_one_register "vmovd" "xmm0" "0xbeef"
+    }
+
+    # regular registers don't have uint128 members, so do it manually.
+    with_test_prefix registers {
+	gdb_test "reverse-step" "vmovd %xmm0, %rcx.*" \
+	    "reverse step to check rcx recording"
+	gdb_test "print/x \$rcx" "= 0x0" "rcx was recorded"
+
+	test_one_register "vmovd" "xmm0" "0x0"
+    }
+
+    # Stop recording to get a clean history.
+    gdb_test "record stop" "Process record is stopped.*" \
+	"delete history for vmov_test"
+} else {
+    untested "could not record vmov_test"
+}
+
+# Move to the end of vmov_test to set up next.
+gdb_test "finish" "Run till exit from.*vmov_test.*" "leaving vmov_test"
diff --git a/gdb/testsuite/gdb.reverse/step-precsave.exp b/gdb/testsuite/gdb.reverse/step-precsave.exp
index 47d494a5d73..03bde745c45 100644
--- a/gdb/testsuite/gdb.reverse/step-precsave.exp
+++ b/gdb/testsuite/gdb.reverse/step-precsave.exp
@@ -47,7 +47,7 @@ with_timeout_factor 20 {
 	    pass $gdb_test_name
 	}
 	-re -wrap "Process record does not support VEX instruction.*" {
-	    kfail "record/23188" $gdb_test_name
+	    kfail "record/17346" $gdb_test_name
 	}
 	-re -wrap "Process record does not support instruction 0xfae64 at.*" {
 	    kfail "record/25038" $gdb_test_name
-- 
2.45.1

[PATCH v2 3/3] gdb/record: add support to AVX unpack instructions

[Guinevere Larsen]

This commit adds support to recording instructions to unpack high
or low data from XMM registers, identified by the mnemonics in the
form: VPUNPCK [L|H] [BW|WD|DQ|QDQ].
All these instructions are encoded the exact same way, and only affect
the destination register, making them trivial to implement together.

It also updates the test gdb.reverse/i386-avx-reverse.exp to test these
new instructions.
---
 gdb/i386-tdep.c                               | 12 ++++++
 gdb/testsuite/gdb.reverse/i386-avx-reverse.c  | 43 +++++++++++++++++++
 .../gdb.reverse/i386-avx-reverse.exp          | 25 +++++++++++
 3 files changed, 80 insertions(+)

diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index b11748be45f..1810cfad744 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -5060,6 +5060,18 @@ i386_record_vex (struct i386_record_s *ir, uint8_t vex_w, uint8_t vex_r,
 	}
       break;
 
+    case 0x60:	/* VPUNPCKLBW  */
+    case 0x61:	/* VPUNPCKLWD  */
+    case 0x62:	/* VPUNPCKLDQ  */
+    case 0x6c:	/* VPUNPCKLQDQ */
+    case 0x68:	/* VPUNPCKHBW  */
+    case 0x69:	/* VPUNPCKHWD  */
+    case 0x6a:	/* VPUNPCKHDQ  */
+    case 0x6d:	/* VPUNPCKHQDQ */
+      i386_record_modrm (ir);
+      record_full_arch_list_add_reg (ir->regcache, ir->regmap[X86_RECORD_XMM0_REGNUM] + ir->reg + vex_r * 8);
+      break;
+
     default:
       gdb_printf (gdb_stderr,
 		  _("Process record does not support VEX instruction 0x%02x "
diff --git a/gdb/testsuite/gdb.reverse/i386-avx-reverse.c b/gdb/testsuite/gdb.reverse/i386-avx-reverse.c
index eeda8b67582..90da0a0c08e 100644
--- a/gdb/testsuite/gdb.reverse/i386-avx-reverse.c
+++ b/gdb/testsuite/gdb.reverse/i386-avx-reverse.c
@@ -76,6 +76,46 @@ vmov_test ()
   return 0; /* end vmov_test */
 }
 
+/* Test if we can properly record (and undo) vpunpck style instructions.
+   Most tests will use xmm0 and xmm1 as sources. The registers xmm15 and xmm2
+   are used as destination to ensure we're reading the VEX.R bit correctly.  */
+int
+vpunpck_test  ()
+{
+  /* Using GDB, load these values onto registers, for ease of testing.
+     xmm0.uint128 = 0x1f1e1d1c1b1a19181716151413121110
+     xmm1.uint128 = 0x2f2e2d2c2b2a29282726252423222120
+     so that's easy to confirm that the unpacking went as expected.  */
+
+  /* start vpunpck_test.  */
+
+  /* 17 27 16 26 15 25 14 24 ...*/
+  asm volatile ("vpunpcklbw  %xmm0, %xmm1, %xmm15");
+  /* 17 16 27 26 15 14 25 24 ...*/
+  asm volatile ("vpunpcklwd  %0, %%xmm1, %%xmm15"
+      : : "m" (global_buf0));
+  /* 17 16 15 14 27 26 25 24 ...*/
+  asm volatile ("vpunpckldq  %0, %%xmm1,  %%xmm2"
+      : : "m" (global_buf0));
+  /* 17 16 15 14 13 12 11 10 ...*/
+  asm volatile ("vpunpcklqdq %xmm0, %xmm1, %xmm2");
+
+  /* 17 27 16 26 15 25 14 24 ...*/
+  asm volatile ("vpunpckhbw  %xmm0, %xmm1, %xmm15");
+  /* 17 16 27 26 15 14 25 24 ...*/
+  asm volatile ("vpunpckhwd  %0, %%xmm1, %%xmm15"
+      : : "m" (global_buf0));
+  /* 17 16 15 14 27 26 25 24 ...*/
+  asm volatile ("vpunpckhdq  %0, %%xmm1,  %%xmm2"
+      : : "m" (global_buf0));
+  /* 17 16 15 14 13 12 11 10 ...*/
+  asm volatile ("vpunpckhqdq %xmm0, %xmm1, %xmm2");
+
+  /* We have a return statement to deal with
+     epilogue in different compilers.  */
+  return 0; /* end vpunpck_test */
+}
+
 int
 main ()
 {
@@ -88,8 +128,11 @@ main ()
     }
   /* Zero relevant xmm registers, se we know what to look for.  */
   asm volatile ("vmovq %0, %%xmm0": : "m" (global_buf1));
+  asm volatile ("vmovq %0, %%xmm1": : "m" (global_buf1));
+  asm volatile ("vmovq %0, %%xmm2": : "m" (global_buf1));
   asm volatile ("vmovq %0, %%xmm15": : "m" (global_buf1));
 
   vmov_test ();
+  vpunpck_test ();
   return 0;	/* end of main */
 }
diff --git a/gdb/testsuite/gdb.reverse/i386-avx-reverse.exp b/gdb/testsuite/gdb.reverse/i386-avx-reverse.exp
index e176428bb10..e048575800e 100644
--- a/gdb/testsuite/gdb.reverse/i386-avx-reverse.exp
+++ b/gdb/testsuite/gdb.reverse/i386-avx-reverse.exp
@@ -176,3 +176,28 @@ if {[record_full_function "vmov"] == true} {
 
 # Move to the end of vmov_test to set up next.
 gdb_test "finish" "Run till exit from.*vmov_test.*" "leaving vmov_test"
+
+# Starting vpunpck tests.
+gdb_test_no_output "set \$xmm0.v2_int64 = {0x1716151413121110, 0x1f1e1d1c1b1a1918}"
+gdb_test_no_output "set \$xmm1.v2_int64 = {0x2726252423222120, 0x2f2e2d2c2b2a2928}"
+gdb_test_no_output "set \$xmm2.uint128 = 0x0"
+gdb_test_no_output "set \$xmm15.uint128 = 0x0"
+if {[record_full_function "vpunpck"] == true} {
+    test_one_register "vpunpckhqdq" "xmm2" "0x"
+    test_one_register "vpunpckhdq" "xmm2" "0x"
+    test_one_register "vpunpckhwd" "xmm15" "0x"
+    test_one_register "vpunpckhbw" "xmm15" "0x"
+
+    test_one_register "vpunpcklqdq" "xmm2" "0x17161514272625241312111023222120"
+    test_one_register "vpunpckldq" "xmm2" "0x0"
+    test_one_register "vpunpcklwd" "xmm15" "0x17271626152514241323122211211020"
+    test_one_register "vpunpcklbw" "xmm15" "0x0"
+} else {
+    untested "couldn't test vpunpck tests"
+}
+
+# Move to the end of vmov_test to set up next.
+# Stop recording in case of recording errors.
+gdb_test "record stop" "Process record is stopped.*" \
+    "delete history for vpunpck_test"
+gdb_test "finish" "Run till exit from.*vpunpck_test.*" "leaving vpunpck_test"
-- 
2.45.1

Re: [PATCH v2 0/3] Small step in supporting AVX instructions

[Guinevere Larsen]

I've made the mistake of wondering about YMM, and noticed that this 
series fails to save the higher bits of the register.

Seeing as it isn't possible to save ymm registers directly yet (more 
info here[1][2]), and I'd like to avoid having to save ymmh and xmm in 
this series, I'll wait until the relevant series get approved before 
sending a v3 of this series

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

On 6/11/24 12:44 PM, Guinevere Larsen wrote:
> This patch series is the first, very small, step in supporting AVX and
> AVX2 instructions for the record-full target. It is important that we
> support it since glibc has been using avx instructions for a long time
> (at least fedora 21), so depending on which functions an inferior uses,
> they might be very inconvenienced.
>
> Patch 1 adds capability to identify the VEX prefix, but no instruction
> support. Patches 2 and 3 add support for a total of 10 instructions,
> which covers around 5% of all AVX instructions used by system libraries
> in my fedora 39 box.
>
> While this support is extremely minimal, I figured I could propose the
> patch series early so it was open for others with more free time could
> help contributing to this :)
>
> ---
> Changes for v2:
> * stopped using "error" when finding incorrect encoding in vmov
>    instructions, as suggested by Tom Tromey.
> * Changed i386-avx-reverse test, to stop failing with clang.
> * Changed the KFAIL in gdb.reverse/step-precsave, so we don't get new
>    FAILs while AVX support is incomplete.
>
> Guinevere Larsen (3):
>    gdb: Start supporting AVX instruction
>    gdb/record: add support to vmovd and vmovq instructions
>    gdb/record: add support to AVX unpack instructions
>
>   gdb/amd64-tdep.c                              |   3 +-
>   gdb/i386-tdep.c                               | 173 ++++++++++++++-
>   gdb/i386-tdep.h                               |   2 +
>   gdb/testsuite/gdb.reverse/i386-avx-reverse.c  | 138 ++++++++++++
>   .../gdb.reverse/i386-avx-reverse.exp          | 203 ++++++++++++++++++
>   gdb/testsuite/gdb.reverse/step-precsave.exp   |   4 +-
>   6 files changed, 518 insertions(+), 5 deletions(-)
>   create mode 100644 gdb/testsuite/gdb.reverse/i386-avx-reverse.c
>   create mode 100644 gdb/testsuite/gdb.reverse/i386-avx-reverse.exp
>

RE: [PATCH v2 0/3] Small step in supporting AVX instructions

[Willgerodt, Felix]

> -----Original Message-----
> From: Guinevere Larsen <blarsen@redhat.com>
> Sent: Montag, 24. Juni 2024 19:49
> To: Guinevere Larsen <blarsen@redhat.com>; gdb-patches@sourceware.org
> Subject: Re: [PATCH v2 0/3] Small step in supporting AVX instructions
> 
> I've made the mistake of wondering about YMM, and noticed that this
> series fails to save the higher bits of the register.
> 
> Seeing as it isn't possible to save ymm registers directly yet (more
> info here[1][2]), and I'd like to avoid having to save ymmh and xmm in
> this series, I'll wait until the relevant series get approved before
> sending a v3 of this series
> 
> --
> Cheers,
> Guinevere Larsen
> She/Her/Hers
> 

Hi Guinevere,

Did you forget to include links for [1] and [2]? I can't find what you are
Referencing in your email. And also can't remember reading anything
related on the mailing list.

And yes the SSE/AVX registers have seen a bit of historical growth, and are
split up over different XSTATE regions. Though I don't see a way around this
split in GDB.

Felix
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH v2 0/3] Small step in supporting AVX instructions

[Guinevere Larsen]

On 6/25/24 4:28 AM, Willgerodt, Felix wrote:
>> -----Original Message-----
>> From: Guinevere Larsen <blarsen@redhat.com>
>> Sent: Montag, 24. Juni 2024 19:49
>> To: Guinevere Larsen <blarsen@redhat.com>; gdb-patches@sourceware.org
>> Subject: Re: [PATCH v2 0/3] Small step in supporting AVX instructions
>>
>> I've made the mistake of wondering about YMM, and noticed that this
>> series fails to save the higher bits of the register.
>>
>> Seeing as it isn't possible to save ymm registers directly yet (more
>> info here[1][2]), and I'd like to avoid having to save ymmh and xmm in
>> this series, I'll wait until the relevant series get approved before
>> sending a v3 of this series
>>
>> --
>> Cheers,
>> Guinevere Larsen
>> She/Her/Hers
>>
> Hi Guinevere,
>
> Did you forget to include links for [1] and [2]? I can't find what you are
> Referencing in your email. And also can't remember reading anything
> related on the mailing list.

oops, yes i did.

[1] 
https://inbox.sourceware.org/gdb-patches/20240621180730.859487-1-blarsen@redhat.com/
[2] 
https://inbox.sourceware.org/gdb-patches/20240621180918.860097-2-blarsen@redhat.com/

>
> And yes the SSE/AVX registers have seen a bit of historical growth, and are
> split up over different XSTATE regions. Though I don't see a way around this
> split in GDB.

Those 5 patches combined should make it possible to read 
pseudo-registers from the regcache we save for the record target.

I say should because I'm still getting some oddities when rebasing my 
series on top of them and testing the changes, though, so I might be 
missing something. I also don't really know anything about XSTATE, so if 
that's also a problem, do let me know!

We could also just save xmm and ymmh registers, but I think using ymm is 
more readable, so I'd prefer to use that if possible.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
> Felix
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928