* [PATCH v2] Support Intel FRED LKGS
@ 2023-05-22 6:07 Zhang, Jun
2023-05-22 9:11 ` Jan Beulich
0 siblings, 1 reply; 17+ messages in thread
From: Zhang, Jun @ 2023-05-22 6:07 UTC (permalink / raw)
To: binutils; +Cc: jbeulich, hjl.tools, jun.zhang
This patch is the second version about Intel FRED and LKGS instructions.
It has fixed all comments except "Ew", because I don't know how to fix it.
Jan, could you help me?
please ignore the previous email.
BRs,
Jun
gas/ChangeLog:
* NEWS: Support Intel FRED LKGS.
* config/tc-i386.c: Add fred lkgs
* doc/c-i386.texi: Document .fred, .lkgs.
* testsuite/gas/i386/i386.exp: Add FRED LKGS tests
* testsuite/gas/i386/x86-64-fred-intel.d: Ditto.
* testsuite/gas/i386/x86-64-fred.d: Ditto.
* testsuite/gas/i386/x86-64-fred.s: Ditto.
* testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto.
* testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto.
* testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto.
* testsuite/gas/i386/x86-64-lkgs.d: Ditto.
* testsuite/gas/i386/x86-64-lkgs.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: New entry for fred, lkgs.
* i386-gen.c: Add CPU_FRED CPU_LKGS.
* i386-init.h : Regenerated.
* i386-mnem.h : Regenerated.
* i386-opc.h: Add fred, lkgs.
* i386-opc.tbl: Add FRED, LKGS instructions.
* i386-tbl.h: Regenerated.
---
gas/NEWS | 4 ++
gas/config/tc-i386.c | 2 +
gas/doc/c-i386.texi | 3 ++
gas/testsuite/gas/i386/i386.exp | 3 ++
gas/testsuite/gas/i386/x86-64-fred-intel.d | 15 ++++++++
gas/testsuite/gas/i386/x86-64-fred.d | 15 ++++++++
gas/testsuite/gas/i386/x86-64-fred.s | 11 ++++++
gas/testsuite/gas/i386/x86-64-lkgs-intel.d | 25 +++++++++++++
gas/testsuite/gas/i386/x86-64-lkgs-inval.l | 9 +++++
gas/testsuite/gas/i386/x86-64-lkgs-inval.s | 14 +++++++
gas/testsuite/gas/i386/x86-64-lkgs.d | 25 +++++++++++++
gas/testsuite/gas/i386/x86-64-lkgs.s | 21 +++++++++++
opcodes/i386-dis.c | 43 +++++++++++++++++++++-
opcodes/i386-gen.c | 4 ++
opcodes/i386-opc.h | 6 +++
opcodes/i386-opc.tbl | 14 +++++++
16 files changed, 212 insertions(+), 2 deletions(-)
create mode 100644 gas/testsuite/gas/i386/x86-64-fred-intel.d
create mode 100644 gas/testsuite/gas/i386/x86-64-fred.d
create mode 100644 gas/testsuite/gas/i386/x86-64-fred.s
create mode 100644 gas/testsuite/gas/i386/x86-64-lkgs-intel.d
create mode 100644 gas/testsuite/gas/i386/x86-64-lkgs-inval.l
create mode 100644 gas/testsuite/gas/i386/x86-64-lkgs-inval.s
create mode 100644 gas/testsuite/gas/i386/x86-64-lkgs.d
create mode 100644 gas/testsuite/gas/i386/x86-64-lkgs.s
diff --git a/gas/NEWS b/gas/NEWS
index 42a2005d7c9..ea172fe9cdb 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -1,5 +1,9 @@
-*- text -*-
+* Add support for Intel FRED instructions.
+
+* Add support for Intel LKGS instructions.
+
* Add support for Intel AMX-COMPLEX instructions.
* Add SME2 support to the AArch64 port.
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index 29b7734b1ac..f30b28eba87 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1141,6 +1141,8 @@ static const arch_entry cpu_arch[] =
SUBARCH (avx_ne_convert, AVX_NE_CONVERT, ANY_AVX_NE_CONVERT, false),
SUBARCH (rao_int, RAO_INT, RAO_INT, false),
SUBARCH (rmpquery, RMPQUERY, ANY_RMPQUERY, false),
+ SUBARCH (fred, FRED, ANY_FRED, false),
+ SUBARCH (lkgs, LKGS, ANY_LKGS, false),
};
#undef SUBARCH
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 15d060b2a33..49b6e3b1abb 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -205,6 +205,8 @@ accept various extension mnemonics. For example,
@code{msrlist},
@code{avx_ne_convert},
@code{rao_int},
+@code{fred},
+@code{lkgs},
@code{amx_int8},
@code{amx_bf16},
@code{amx_fp16},
@@ -1634,6 +1636,7 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.prefetchi} @tab @samp{.avx_ifma} @tab @samp{.avx_vnni_int8}
@item @samp{.cmpccxadd} @tab @samp{.wrmsrns} @tab @samp{.msrlist}
@item @samp{.avx_ne_convert} @tab @samp{.rao_int}
+@item @samp{.fred} @tab @samp{.lkgs}
@item @samp{.wbnoinvd} @tab @samp{.pconfig} @tab @samp{.waitpkg} @tab @samp{.cldemote}
@item @samp{.shstk} @tab @samp{.gfni} @tab @samp{.vaes} @tab @samp{.vpclmulqdq}
@item @samp{.movdiri} @tab @samp{.movdir64b} @tab @samp{.enqcmd} @tab @samp{.tsxldtrk}
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 40e75ac6f88..e2958fd552f 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -1189,6 +1189,9 @@ if [gas_64_check] then {
run_dump_test "x86-64-amx-complex-intel"
run_dump_test "x86-64-amx-complex-bad"
run_list_test "x86-64-amx-complex-inval"
+ run_dump_test "x86-64-fred"
+ run_dump_test "x86-64-lkgs"
+ run_list_test "x86-64-lkgs-inval"
run_dump_test "x86-64-clzero"
run_dump_test "x86-64-mwaitx-bdver4"
run_list_test "x86-64-mwaitx-reg"
diff --git a/gas/testsuite/gas/i386/x86-64-fred-intel.d b/gas/testsuite/gas/i386/x86-64-fred-intel.d
new file mode 100644
index 00000000000..aef98af2d81
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-fred-intel.d
@@ -0,0 +1,15 @@
+#as:
+#objdump: -dw -Mintel
+#name: x86_64 FRED insns (Intel disassembly)
+#source: x86-64-fred.s
+
+.*: +file format .*
+
+Disassembly of section \.text:
+
+0+ <_start>:
+\s*[a-f0-9]+:\s*f2 0f 01 ca\s+erets
+\s*[a-f0-9]+:\s*f3 0f 01 ca\s+eretu
+\s*[a-f0-9]+:\s*f2 0f 01 ca\s+erets
+\s*[a-f0-9]+:\s*f3 0f 01 ca\s+eretu
+#pass
diff --git a/gas/testsuite/gas/i386/x86-64-fred.d b/gas/testsuite/gas/i386/x86-64-fred.d
new file mode 100644
index 00000000000..01990f1cec8
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-fred.d
@@ -0,0 +1,15 @@
+#as:
+#objdump: -dw
+#name: x86_64 FRED insns
+#source: x86-64-fred.s
+
+.*: +file format .*
+
+Disassembly of section \.text:
+
+0+ <_start>:
+\s*[a-f0-9]+:\s*f2 0f 01 ca\s+erets
+\s*[a-f0-9]+:\s*f3 0f 01 ca\s+eretu
+\s*[a-f0-9]+:\s*f2 0f 01 ca\s+erets
+\s*[a-f0-9]+:\s*f3 0f 01 ca\s+eretu
+#pass
diff --git a/gas/testsuite/gas/i386/x86-64-fred.s b/gas/testsuite/gas/i386/x86-64-fred.s
new file mode 100644
index 00000000000..0e5d3d3d469
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-fred.s
@@ -0,0 +1,11 @@
+# Check 64bit FRED instructions
+
+ .allow_index_reg
+ .text
+_start:
+ erets #FRED
+ eretu #FRED
+
+.intel_syntax noprefix
+ erets #FRED
+ eretu #FRED
diff --git a/gas/testsuite/gas/i386/x86-64-lkgs-intel.d b/gas/testsuite/gas/i386/x86-64-lkgs-intel.d
new file mode 100644
index 00000000000..0f4a6fba6d3
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-lkgs-intel.d
@@ -0,0 +1,25 @@
+#as:
+#objdump: -dw -Mintel
+#name: x86_64 LKGS insns (Intel disassembly)
+#source: x86-64-lkgs.s
+
+.*: +file format .*
+
+Disassembly of section \.text:
+
+0+ <_start>:
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs r12w
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs r12w
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs r12w
+\s*[a-f0-9]+:\s*f2 42 0f 00 b4 f5 00 00 00 10\s+lkgs WORD PTR \[rbp\+r14\*8\+0x10000000\]
+\s*[a-f0-9]+:\s*f2 41 0f 00 31\s+lkgs WORD PTR \[r9\]
+\s*[a-f0-9]+:\s*f2 0f 00 b1 fe 00 00 00\s+lkgs WORD PTR \[rcx\+0xfe\]
+\s*[a-f0-9]+:\s*f2 0f 00 b2 00 ff ff ff\s+lkgs WORD PTR \[rdx-0x100\]
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs r12w
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs r12w
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs r12w
+\s*[a-f0-9]+:\s*f2 42 0f 00 b4 f5 00 00 00 10\s+lkgs WORD PTR \[rbp\+r14\*8\+0x10000000\]
+\s*[a-f0-9]+:\s*f2 41 0f 00 31\s+lkgs WORD PTR \[r9\]
+\s*[a-f0-9]+:\s*f2 0f 00 b1 fe 00 00 00\s+lkgs WORD PTR \[rcx\+0xfe\]
+\s*[a-f0-9]+:\s*f2 0f 00 b2 00 ff ff ff\s+lkgs WORD PTR \[rdx-0x100\]
+#pass
diff --git a/gas/testsuite/gas/i386/x86-64-lkgs-inval.l b/gas/testsuite/gas/i386/x86-64-lkgs-inval.l
new file mode 100644
index 00000000000..77ee7d7c8b9
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-lkgs-inval.l
@@ -0,0 +1,9 @@
+.* Assembler messages:
+.*:5: Error: invalid instruction suffix for `lkgs'
+.*:6: Error: invalid instruction suffix for `lkgs'
+.*:7: Error: invalid instruction suffix for `lkgs'
+.*:8: Error: invalid instruction suffix for `lkgs'
+.*:11: Error: invalid instruction suffix for `lkgs'
+.*:12: Error: invalid instruction suffix for `lkgs'
+.*:13: Error: invalid instruction suffix for `lkgs'
+.*:14: Error: invalid instruction suffix for `lkgs'
diff --git a/gas/testsuite/gas/i386/x86-64-lkgs-inval.s b/gas/testsuite/gas/i386/x86-64-lkgs-inval.s
new file mode 100644
index 00000000000..1dbce14bae4
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-lkgs-inval.s
@@ -0,0 +1,14 @@
+# Check illegal 64bit suffer usage in LKGS instructions
+
+ .text
+_start:
+ lkgsb %r12 #LKGS
+ lkgss %r12 #LKGS
+ lkgsb (%r9) #LKGS
+ lkgss (%r9) #LKGS
+
+ .intel_syntax noprefix
+ lkgsb %r12 #LKGS
+ lkgsb BYTE PTR [r9] #LKGS
+ lkgsd DWORD PTR [r9] #LKGS
+ lkgsq QWORD PTR [r9] #LKGS
diff --git a/gas/testsuite/gas/i386/x86-64-lkgs.d b/gas/testsuite/gas/i386/x86-64-lkgs.d
new file mode 100644
index 00000000000..207143da574
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-lkgs.d
@@ -0,0 +1,25 @@
+#as:
+#objdump: -dw
+#name: x86_64 LKGS insns
+#source: x86-64-lkgs.s
+
+.*: +file format .*
+
+Disassembly of section \.text:
+
+0+ <_start>:
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs %r12w
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs %r12w
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs %r12w
+\s*[a-f0-9]+:\s*f2 42 0f 00 b4 f5 00 00 00 10\s+lkgs 0x10000000\(%rbp,%r14,8\)
+\s*[a-f0-9]+:\s*f2 41 0f 00 31\s+lkgs \(%r9\)
+\s*[a-f0-9]+:\s*f2 0f 00 b1 fe 00 00 00\s+lkgs 0xfe\(%rcx\)
+\s*[a-f0-9]+:\s*f2 0f 00 b2 00 ff ff ff\s+lkgs -0x100\(%rdx\)
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs %r12w
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs %r12w
+\s*[a-f0-9]+:\s*f2 41 0f 00 f4\s+lkgs %r12w
+\s*[a-f0-9]+:\s*f2 42 0f 00 b4 f5 00 00 00 10\s+lkgs 0x10000000\(%rbp,%r14,8\)
+\s*[a-f0-9]+:\s*f2 41 0f 00 31\s+lkgs \(%r9\)
+\s*[a-f0-9]+:\s*f2 0f 00 b1 fe 00 00 00\s+lkgs 0xfe\(%rcx\)
+\s*[a-f0-9]+:\s*f2 0f 00 b2 00 ff ff ff\s+lkgs -0x100\(%rdx\)
+#pass
diff --git a/gas/testsuite/gas/i386/x86-64-lkgs.s b/gas/testsuite/gas/i386/x86-64-lkgs.s
new file mode 100644
index 00000000000..546bbcc580a
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-lkgs.s
@@ -0,0 +1,21 @@
+# Check 64bit LKGS instructions
+
+ .allow_index_reg
+ .text
+_start:
+ lkgs %r12 #LKGS
+ lkgs %r12w #LKGS
+ lkgsw %r12w #LKGS
+ lkgs 0x10000000(%rbp, %r14, 8) #LKGS
+ lkgs (%r9) #LKGS
+ lkgs 254(%rcx) #LKGS Disp32(fe000000)
+ lkgs -256(%rdx) #LKGS Disp32(00ffffff)
+
+.intel_syntax noprefix
+ lkgs r12 #LKGS
+ lkgs r12w #LKGS
+ lkgsw r12w #LKGS
+ lkgs WORD PTR [rbp+r14*8+0x10000000] #LKGS
+ lkgs WORD PTR [r9] #LKGS
+ lkgs WORD PTR [rcx+254] #LKGS Disp32(fe000000)
+ lkgs WORD PTR [rdx-256] #LKGS Disp32(00ffffff)
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index b529fe705bc..1a0b5e4fb10 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -1025,7 +1025,9 @@ enum
enum
{
PREFIX_90 = 0,
+ PREFIX_0F00_REG_6_X86_64,
PREFIX_0F01_REG_0_MOD_3_RM_6,
+ PREFIX_0F01_REG_1_RM_2,
PREFIX_0F01_REG_1_RM_4,
PREFIX_0F01_REG_1_RM_5,
PREFIX_0F01_REG_1_RM_6,
@@ -1310,10 +1312,13 @@ enum
X86_64_E8,
X86_64_E9,
X86_64_EA,
+ X86_64_0F00_REG_6,
X86_64_0F01_REG_0,
X86_64_0F01_REG_0_MOD_3_RM_6_P_1,
X86_64_0F01_REG_0_MOD_3_RM_6_P_3,
X86_64_0F01_REG_1,
+ X86_64_0F01_REG_1_RM_2_PREFIX_1,
+ X86_64_0F01_REG_1_RM_2_PREFIX_3,
X86_64_0F01_REG_1_RM_5_PREFIX_2,
X86_64_0F01_REG_1_RM_6_PREFIX_2,
X86_64_0F01_REG_1_RM_7_PREFIX_2,
@@ -2755,7 +2760,7 @@ static const struct dis386 reg_table[][8] = {
{ "ltr", { Ew }, 0 },
{ "verr", { Ew }, 0 },
{ "verw", { Ew }, 0 },
- { Bad_Opcode },
+ { X86_64_TABLE (X86_64_0F00_REG_6) },
{ Bad_Opcode },
},
/* REG_0F01 */
@@ -2996,6 +3001,14 @@ static const struct dis386 prefix_table[][4] = {
{ NULL, { { NULL, 0 } }, PREFIX_IGNORED }
},
+ /* PREFIX_0F00_REG_6_X86_64 */
+ {
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { "lkgs", { Ew }, 0 },
+ },
+
/* PREFIX_0F01_REG_0_MOD_3_RM_6 */
{
{ "wrmsrns", { Skip_MODRM }, 0 },
@@ -3004,6 +3017,14 @@ static const struct dis386 prefix_table[][4] = {
{ X86_64_TABLE (X86_64_0F01_REG_0_MOD_3_RM_6_P_3) },
},
+ /* PREFIX_0F01_REG_1_RM_2 */
+ {
+ { "clac", { Skip_MODRM }, 0 },
+ { X86_64_TABLE (X86_64_0F01_REG_1_RM_2_PREFIX_1) },
+ { Bad_Opcode },
+ { X86_64_TABLE (X86_64_0F01_REG_1_RM_2_PREFIX_3)},
+ },
+
/* PREFIX_0F01_REG_1_RM_4 */
{
{ Bad_Opcode },
@@ -4371,6 +4392,12 @@ static const struct dis386 x86_64_table[][2] = {
{ "{l|}jmp{P|}", { Ap }, 0 },
},
+ /* X86_64_0F00_REG_6 */
+ {
+ { Bad_Opcode },
+ { PREFIX_TABLE (PREFIX_0F00_REG_6_X86_64) },
+ },
+
/* X86_64_0F01_REG_0 */
{
{ "sgdt{Q|Q}", { M }, 0 },
@@ -4395,6 +4422,18 @@ static const struct dis386 x86_64_table[][2] = {
{ "sidt", { M }, 0 },
},
+ /* X86_64_0F01_REG_1_RM_2_PREFIX_1 */
+ {
+ { Bad_Opcode },
+ { "eretu", { Skip_MODRM }, 0 },
+ },
+
+ /* X86_64_0F01_REG_1_RM_2_PREFIX_3 */
+ {
+ { Bad_Opcode },
+ { "erets", { Skip_MODRM }, 0 },
+ },
+
/* X86_64_0F01_REG_1_RM_5_PREFIX_2 */
{
{ Bad_Opcode },
@@ -8702,7 +8741,7 @@ static const struct dis386 rm_table[][8] = {
/* RM_0F01_REG_1 */
{ "monitor", { { OP_Monitor, 0 } }, 0 },
{ "mwait", { { OP_Mwait, 0 } }, 0 },
- { "clac", { Skip_MODRM }, 0 },
+ { PREFIX_TABLE (PREFIX_0F01_REG_1_RM_2) },
{ "stac", { Skip_MODRM }, 0 },
{ PREFIX_TABLE (PREFIX_0F01_REG_1_RM_4) },
{ PREFIX_TABLE (PREFIX_0F01_REG_1_RM_5) },
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index c2ac3c6832d..1db555d8615 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -164,6 +164,8 @@ static const dependency isa_dependencies[] =
"AVX2" },
{ "AVX_NE_CONVERT",
"AVX2" },
+ { "FRED",
+ "LKGS" },
{ "AVX512F",
"AVX2" },
{ "AVX512CD",
@@ -362,6 +364,8 @@ static bitfield cpu_flags[] =
BITFIELD (MSRLIST),
BITFIELD (AVX_NE_CONVERT),
BITFIELD (RAO_INT),
+ BITFIELD (FRED),
+ BITFIELD (LKGS),
BITFIELD (MWAITX),
BITFIELD (CLZERO),
BITFIELD (OSPKE),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index b17e8341aa2..d65392aca8d 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -229,6 +229,10 @@ enum
CpuAVX_NE_CONVERT,
/* Intel RAO INT Instructions support required. */
CpuRAO_INT,
+ /* fred instruction required */
+ CpuFRED,
+ /* lkgs instruction required */
+ CpuLKGS,
/* mwaitx instruction required */
CpuMWAITX,
/* Clzero instruction required */
@@ -424,6 +428,8 @@ typedef union i386_cpu_flags
unsigned int cpumsrlist:1;
unsigned int cpuavx_ne_convert:1;
unsigned int cpurao_int:1;
+ unsigned int cpufred:1;
+ unsigned int cpulkgs:1;
unsigned int cpumwaitx:1;
unsigned int cpuclzero:1;
unsigned int cpuospke:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 15d48eeb4c7..a4db19c001a 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -3351,3 +3351,17 @@ aor, 0xf20f38fc, RAO_INT, Modrm|IgnoreSize|CheckOperandSize|NoSuf, { Reg32|Reg64
axor, 0xf30f38fc, RAO_INT, Modrm|IgnoreSize|CheckOperandSize|NoSuf, { Reg32|Reg64, Dword|Qword|Unspecified|BaseIndex }
// RAO-INT instructions end.
+
+// FRED instructions.
+
+erets, 0xf20f01ca, FRED|x64, NoSuf, {}
+eretu, 0xf30f01ca, FRED|x64, NoSuf, {}
+
+// FRED instructions end.
+
+// LKGS instructions.
+
+lkgs, 0xf20f00/6, LKGS|x64, Modrm|IgnoreSize|No_bSuf|No_sSuf|NoRex64, { Reg16|Reg32|Reg64 }
+lkgs, 0xf20f00/6, LKGS|x64, Modrm|IgnoreSize|No_bSuf|No_lSuf|No_sSuf|No_qSuf, { Word|Unspecified|BaseIndex }
+
+// LKGS instructions end.
--
2.25.1
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] Support Intel FRED LKGS
2023-05-22 6:07 [PATCH v2] Support Intel FRED LKGS Zhang, Jun
@ 2023-05-22 9:11 ` Jan Beulich
2023-05-24 6:36 ` Jiang, Haochen
0 siblings, 1 reply; 17+ messages in thread
From: Jan Beulich @ 2023-05-22 9:11 UTC (permalink / raw)
To: Zhang, Jun; +Cc: hjl.tools, binutils
On 22.05.2023 08:07, Zhang, Jun wrote:
> This patch is the second version about Intel FRED and LKGS instructions.
> It has fixed all comments except "Ew", because I don't know how to fix it.
> Jan, could you help me?
Well, there are two ways of approaching this, but imo in either case via
a prereq change to the other insns that use this operand descriptor in a
questionable manner. We could split decode at the ModR/M.mod level, but
perhaps better is to follow MOV to/from sreg, SLDT, and STR in using a D
suffix and an Sv operand.
If, however, you're not happy about making the prereq change first, I'd
be kind of okay with the change being committed as is, and I'd then try
to remember to follow up accordingly. One minor adjustment request,
though: In the opcode table comments, can you please use singular for
LKGS (while plural is fine for FRED)?
Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [PATCH v2] Support Intel FRED LKGS
2023-05-22 9:11 ` Jan Beulich
@ 2023-05-24 6:36 ` Jiang, Haochen
2023-05-25 7:57 ` Jiang, Haochen
0 siblings, 1 reply; 17+ messages in thread
From: Jiang, Haochen @ 2023-05-24 6:36 UTC (permalink / raw)
To: Beulich, Jan, Zhang, Jun; +Cc: hjl.tools, binutils
> Well, there are two ways of approaching this, but imo in either case via
> a prereq change to the other insns that use this operand descriptor in a
> questionable manner. We could split decode at the ModR/M.mod level, but
> perhaps better is to follow MOV to/from sreg, SLDT, and STR in using a D
> suffix and an Sv operand.
I suppose the latter is better since Sv will go back to OP_E then split decode
ad ModR/M.mod level.
I will go through that to make the change.
Thx,
Haochen
>
> If, however, you're not happy about making the prereq change first, I'd
> be kind of okay with the change being committed as is, and I'd then try
> to remember to follow up accordingly. One minor adjustment request,
> though: In the opcode table comments, can you please use singular for
> LKGS (while plural is fine for FRED)?
>
> Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [PATCH v2] Support Intel FRED LKGS
2023-05-24 6:36 ` Jiang, Haochen
@ 2023-05-25 7:57 ` Jiang, Haochen
2023-05-25 8:42 ` Jan Beulich
0 siblings, 1 reply; 17+ messages in thread
From: Jiang, Haochen @ 2023-05-25 7:57 UTC (permalink / raw)
To: Beulich, Jan, Zhang, Jun; +Cc: hjl.tools, binutils
> > Well, there are two ways of approaching this, but imo in either case
> > via a prereq change to the other insns that use this operand
> > descriptor in a questionable manner. We could split decode at the
> > ModR/M.mod level, but perhaps better is to follow MOV to/from sreg,
> > SLDT, and STR in using a D suffix and an Sv operand.
>
> I suppose the latter is better since Sv will go back to OP_E then split decode
> ad ModR/M.mod level.
>
> I will go through that to make the change.
>
> Thx,
> Haochen
I just take a look at the whole thing.
From my perspective, if we are going to use the same pattern like
SLDT and STR. Does that mean for the instruction below:
lldt %ax
We will need to add a 66 prefix for gas to make it happen or it will drop to %eax?
It will change the current assembler behavior. Is my understanding correct?
Haochen
>
> >
> > If, however, you're not happy about making the prereq change first,
> > I'd be kind of okay with the change being committed as is, and I'd
> > then try to remember to follow up accordingly. One minor adjustment
> > request,
> > though: In the opcode table comments, can you please use singular for
> > LKGS (while plural is fine for FRED)?
> >
> > Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] Support Intel FRED LKGS
2023-05-25 7:57 ` Jiang, Haochen
@ 2023-05-25 8:42 ` Jan Beulich
2023-05-26 6:50 ` Jiang, Haochen
0 siblings, 1 reply; 17+ messages in thread
From: Jan Beulich @ 2023-05-25 8:42 UTC (permalink / raw)
To: Jiang, Haochen; +Cc: hjl.tools, binutils, Zhang, Jun
On 25.05.2023 09:57, Jiang, Haochen wrote:
>>> Well, there are two ways of approaching this, but imo in either case
>>> via a prereq change to the other insns that use this operand
>>> descriptor in a questionable manner. We could split decode at the
>>> ModR/M.mod level, but perhaps better is to follow MOV to/from sreg,
>>> SLDT, and STR in using a D suffix and an Sv operand.
>>
>> I suppose the latter is better since Sv will go back to OP_E then split decode
>> ad ModR/M.mod level.
>>
>> I will go through that to make the change.
>>
>> Thx,
>> Haochen
>
> I just take a look at the whole thing.
>
> From my perspective, if we are going to use the same pattern like
> SLDT and STR. Does that mean for the instruction below:
>
> lldt %ax
>
> We will need to add a 66 prefix for gas to make it happen or it will drop to %eax?
>
> It will change the current assembler behavior. Is my understanding correct?
No. The assembler was changed already. The disassembler simply wants
to follow suit. IOW the assembler already avoids emitting any unnecessary
prefixes. The disassembler, otoh, should correctly represent redundant
prefixes (and preferably not as raw ones, e.g. not "data16" but a 16-bit
sized register or an insn suffix for AT&T memory operands).
Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [PATCH v2] Support Intel FRED LKGS
2023-05-25 8:42 ` Jan Beulich
@ 2023-05-26 6:50 ` Jiang, Haochen
2023-05-26 7:00 ` Jan Beulich
0 siblings, 1 reply; 17+ messages in thread
From: Jiang, Haochen @ 2023-05-26 6:50 UTC (permalink / raw)
To: Beulich, Jan; +Cc: hjl.tools, binutils, Zhang, Jun
> > I just take a look at the whole thing.
> >
> > From my perspective, if we are going to use the same pattern like SLDT
> > and STR. Does that mean for the instruction below:
> >
> > lldt %ax
> >
> > We will need to add a 66 prefix for gas to make it happen or it will drop
> to %eax?
> >
> > It will change the current assembler behavior. Is my understanding correct?
>
> No. The assembler was changed already. The disassembler simply wants to
> follow suit. IOW the assembler already avoids emitting any unnecessary
> prefixes. The disassembler, otoh, should correctly represent redundant
> prefixes (and preferably not as raw ones, e.g. not "data16" but a 16-bit sized
> register or an insn suffix for AT&T memory operands).
So for all the registers, is the ideal case that we should not emit suffixes since the
register will always be 16 bit?
If we are using D, I suppose we will emit suffixes under the current scenario.
Haochen
>
> Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] Support Intel FRED LKGS
2023-05-26 6:50 ` Jiang, Haochen
@ 2023-05-26 7:00 ` Jan Beulich
2023-05-26 8:26 ` [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr Haochen Jiang
0 siblings, 1 reply; 17+ messages in thread
From: Jan Beulich @ 2023-05-26 7:00 UTC (permalink / raw)
To: Jiang, Haochen; +Cc: hjl.tools, binutils, Zhang, Jun
On 26.05.2023 08:50, Jiang, Haochen wrote:
>
>>> I just take a look at the whole thing.
>>>
>>> From my perspective, if we are going to use the same pattern like SLDT
>>> and STR. Does that mean for the instruction below:
>>>
>>> lldt %ax
>>>
>>> We will need to add a 66 prefix for gas to make it happen or it will drop
>> to %eax?
>>>
>>> It will change the current assembler behavior. Is my understanding correct?
>>
>> No. The assembler was changed already. The disassembler simply wants to
>> follow suit. IOW the assembler already avoids emitting any unnecessary
>> prefixes. The disassembler, otoh, should correctly represent redundant
>> prefixes (and preferably not as raw ones, e.g. not "data16" but a 16-bit sized
>> register or an insn suffix for AT&T memory operands).
>
> So for all the registers, is the ideal case that we should not emit suffixes since the
> register will always be 16 bit?
The _part of the register that's used_ is always 16 bits. That doesn't mean
that's what we need to print. See e.g. pextrw/pinsrw. Imo GPRs here (like
elsewhere) should be printed according to the present prefixes: 16-bit when
a data size prefix is present, 32-bit when no size prefix is present, and
64-bit when REX.W is present. (Obviously adjusted when dealing with 16-bit
code.) This then eliminates the need for any insn suffix; that'll be needed
only for suffix-always mode, and specifically not for memory operands (which
are always 16-bit) outside of suffix-always mode. If this isn't what Sv + D
do, then it probably needs adjusting.
Jan
> If we are using D, I suppose we will emit suffixes under the current scenario.
>
> Haochen
>
>>
>> Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr
2023-05-26 7:00 ` Jan Beulich
@ 2023-05-26 8:26 ` Haochen Jiang
2023-05-26 8:46 ` Jan Beulich
2023-06-01 2:14 ` H.J. Lu
0 siblings, 2 replies; 17+ messages in thread
From: Haochen Jiang @ 2023-05-26 8:26 UTC (permalink / raw)
To: binutils, jbeulich; +Cc: hjl.tools, jun.zhang
Hi Jan,
I am trying to fix the questionable manner with this patch. See if it reaches
all our expectation.
Thx,
Haochen
Currently, for instructions lldt/ltr/verr/verw/lkgs, we are missing
w suffix for memory operands like sldt/str do. Also the Ew usage is
not that precise under this scenario. Add Evw to fix this problem.
gas/ChangeLog:
* testsuite/gas/i386/i386.exp: Add LKGS suffix test.
* testsuite/gas/i386/opcode-intel.d: Add ltr, verr, verw.
* testsuite/gas/i386/opcode-suffix.d: Ditto.
* testsuite/gas/i386/opcode.d: Ditto.
* testsuite/gas/i386/opcode.s: Ditto.
* testsuite/gas/i386/x86-64-lkgs-suffix.d: New test.
* testsuite/gas/i386/x86-64-lkgs-suffix.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c (Evw): New.
(v_w_mode): Ditto.
(lldt, ltr, verr, verw, lkgs): Change from Ew to Evw.
(intel_operand_size): Handle v_w_mode.
(print_register): Ditto.
---
gas/testsuite/gas/i386/i386.exp | 1 +
gas/testsuite/gas/i386/opcode-intel.d | 3 +++
gas/testsuite/gas/i386/opcode-suffix.d | 5 ++++-
gas/testsuite/gas/i386/opcode.d | 3 +++
gas/testsuite/gas/i386/opcode.s | 4 ++++
gas/testsuite/gas/i386/x86-64-lkgs-suffix.d | 15 +++++++++++++++
gas/testsuite/gas/i386/x86-64-lkgs-suffix.s | 7 +++++++
opcodes/i386-dis.c | 20 +++++++++++++++-----
8 files changed, 52 insertions(+), 6 deletions(-)
create mode 100644 gas/testsuite/gas/i386/x86-64-lkgs-suffix.d
create mode 100644 gas/testsuite/gas/i386/x86-64-lkgs-suffix.s
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index bce865c83d1..58f32401610 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -1194,6 +1194,7 @@ if [gas_64_check] then {
run_list_test "x86-64-amx-complex-inval"
run_dump_test "x86-64-fred"
run_dump_test "x86-64-lkgs"
+ run_dump_test "x86-64-lkgs-suffix"
run_list_test "x86-64-lkgs-inval"
run_dump_test "x86-64-clzero"
run_dump_test "x86-64-mwaitx-bdver4"
diff --git a/gas/testsuite/gas/i386/opcode-intel.d b/gas/testsuite/gas/i386/opcode-intel.d
index 7f641db2892..3a366757a6a 100644
--- a/gas/testsuite/gas/i386/opcode-intel.d
+++ b/gas/testsuite/gas/i386/opcode-intel.d
@@ -589,6 +589,9 @@ Disassembly of section .text:
*[0-9a-f]+: 85 d8 [ ]*test[ ]+eax,ebx
*[0-9a-f]+: 85 18 [ ]*test[ ]+(DWORD PTR )?\[eax\],ebx
*[0-9a-f]+: f1[ ]+int1
+ *[0-9a-f]+: 0f 00 98 90 90 90 90[ ]+ltr[ ]+(WORD PTR )?\[eax-0x6f6f6f70\]
+ *[0-9a-f]+: 0f 00 a0 90 90 90 90[ ]+verr[ ]+(WORD PTR )?\[eax-0x6f6f6f70\]
+ *[0-9a-f]+: 0f 00 a8 90 90 90 90[ ]+verw[ ]+(WORD PTR )?\[eax-0x6f6f6f70\]
[ ]*[a-f0-9]+: 0f 4a 90 90 90 90 90 cmovp edx,DWORD PTR \[eax-0x6f6f6f70\]
[ ]*[a-f0-9]+: 0f 4b 90 90 90 90 90 cmovnp edx,DWORD PTR \[eax-0x6f6f6f70\]
[ ]*[a-f0-9]+: 66 0f 4a 90 90 90 90 90 cmovp dx,WORD PTR \[eax-0x6f6f6f70\]
diff --git a/gas/testsuite/gas/i386/opcode-suffix.d b/gas/testsuite/gas/i386/opcode-suffix.d
index 152c3b865a0..fdca16a8a6b 100644
--- a/gas/testsuite/gas/i386/opcode-suffix.d
+++ b/gas/testsuite/gas/i386/opcode-suffix.d
@@ -248,7 +248,7 @@ Disassembly of section .text:
*[0-9a-f]+: fc[ ]+cld
*[0-9a-f]+: fd[ ]+std
*[0-9a-f]+: ff 90 90 90 90 90[ ]+calll[ ]+\*-0x6f6f6f70\(%eax\)
- *[0-9a-f]+: 0f 00 90 90 90 90 90[ ]+lldt[ ]+-0x6f6f6f70\(%eax\)
+ *[0-9a-f]+: 0f 00 90 90 90 90 90[ ]+lldtw[ ]+-0x6f6f6f70\(%eax\)
*[0-9a-f]+: 0f 01 90 90 90 90 90[ ]+lgdtl[ ]+-0x6f6f6f70\(%eax\)
*[0-9a-f]+: 0f 02 90 90 90 90 90[ ]+larl[ ]+-0x6f6f6f70\(%eax\),%edx
*[0-9a-f]+: 0f 03 90 90 90 90 90[ ]+lsll[ ]+-0x6f6f6f70\(%eax\),%edx
@@ -589,6 +589,9 @@ Disassembly of section .text:
*[0-9a-f]+: 85 d8 [ ]*testl[ ]+%ebx,%eax
*[0-9a-f]+: 85 18 [ ]*testl[ ]+%ebx,\(%eax\)
*[0-9a-f]+: f1[ ]+int1
+ *[0-9a-f]+: 0f 00 98 90 90 90 90[ ]+ltrw[ ]+-0x6f6f6f70\(%eax\)
+ *[0-9a-f]+: 0f 00 a0 90 90 90 90[ ]+verrw[ ]+-0x6f6f6f70\(%eax\)
+ *[0-9a-f]+: 0f 00 a8 90 90 90 90[ ]+verww[ ]+-0x6f6f6f70\(%eax\)
[ ]*[a-f0-9]+: 0f 4a 90 90 90 90 90 cmovpl -0x6f6f6f70\(%eax\),%edx
[ ]*[a-f0-9]+: 0f 4b 90 90 90 90 90 cmovnpl -0x6f6f6f70\(%eax\),%edx
[ ]*[a-f0-9]+: 66 0f 4a 90 90 90 90 90 cmovpw -0x6f6f6f70\(%eax\),%dx
diff --git a/gas/testsuite/gas/i386/opcode.d b/gas/testsuite/gas/i386/opcode.d
index c6ffb018a19..e792962f3c1 100644
--- a/gas/testsuite/gas/i386/opcode.d
+++ b/gas/testsuite/gas/i386/opcode.d
@@ -588,6 +588,9 @@ Disassembly of section .text:
9f7: 85 d8 [ ]*test %ebx,%eax
9f9: 85 18 [ ]*test %ebx,\(%eax\)
9fb: f1 [ ]*int1
+ +[a-f0-9]+: 0f 00 98 90 90 90 90 ltr -0x6f6f6f70\(%eax\)
+ +[a-f0-9]+: 0f 00 a0 90 90 90 90 verr -0x6f6f6f70\(%eax\)
+ +[a-f0-9]+: 0f 00 a8 90 90 90 90 verw -0x6f6f6f70\(%eax\)
[ ]*[a-f0-9]+: 0f 4a 90 90 90 90 90 cmovp -0x6f6f6f70\(%eax\),%edx
[ ]*[a-f0-9]+: 0f 4b 90 90 90 90 90 cmovnp -0x6f6f6f70\(%eax\),%edx
[ ]*[a-f0-9]+: 66 0f 4a 90 90 90 90 90 cmovp -0x6f6f6f70\(%eax\),%dx
diff --git a/gas/testsuite/gas/i386/opcode.s b/gas/testsuite/gas/i386/opcode.s
index 000fff3e852..800dc465f70 100644
--- a/gas/testsuite/gas/i386/opcode.s
+++ b/gas/testsuite/gas/i386/opcode.s
@@ -587,6 +587,10 @@ foo:
int1
+ ltr 0x90909090(%eax)
+ verr 0x90909090(%eax)
+ verw 0x90909090(%eax)
+
cmovpe 0x90909090(%eax),%edx
cmovpo 0x90909090(%eax),%edx
cmovpe 0x90909090(%eax),%dx
diff --git a/gas/testsuite/gas/i386/x86-64-lkgs-suffix.d b/gas/testsuite/gas/i386/x86-64-lkgs-suffix.d
new file mode 100644
index 00000000000..5433938f54d
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-lkgs-suffix.d
@@ -0,0 +1,15 @@
+#as: -J --divide
+#objdump: -dwMsuffix
+#name: x86_64 LKGS insns (w/ suffix)
+#source: x86-64-lkgs.d
+
+.*: +file format .*
+
+Disassembly of section \.text:
+
+0+ <_start>:
+\s*[a-f0-9]+:\s*f2 42 0f 00 b4 f5 00 00 00 10\s+lkgsw 0x10000000\(%rbp,%r14,8\)
+\s*[a-f0-9]+:\s*f2 41 0f 00 31\s+lkgsw \(%r9\)
+\s*[a-f0-9]+:\s*f2 0f 00 b1 fe 00 00 00\s+lkgsw 0xfe\(%rcx\)
+\s*[a-f0-9]+:\s*f2 0f 00 b2 00 ff ff ff\s+lkgsw -0x100\(%rdx\)
+#pass
diff --git a/gas/testsuite/gas/i386/x86-64-lkgs-suffix.s b/gas/testsuite/gas/i386/x86-64-lkgs-suffix.s
new file mode 100644
index 00000000000..a8a77e34d0c
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-lkgs-suffix.s
@@ -0,0 +1,7 @@
+ .allow_index_reg
+ .text
+_start:
+ lkgs 0x10000000(%rbp, %r14, 8)
+ lkgs (%r9)
+ lkgs 254(%rcx)
+ lkgs -256(%rdx)
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 07fcf3269f9..1dfa7e2b71c 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -387,6 +387,7 @@ fetch_error (const instr_info *ins)
#define Eva { OP_E, va_mode }
#define Ev_bnd { OP_E, v_bnd_mode }
#define EvS { OP_E, v_swap_mode }
+#define Evw { OP_E, v_w_mode }
#define Ed { OP_E, d_mode }
#define Edq { OP_E, dq_mode }
#define Edb { OP_E, db_mode }
@@ -605,6 +606,8 @@ enum
v_swap_mode,
/* operand size depends on address prefix */
va_mode,
+ /* operand size depends on prefixes but ignore DFLAG */
+ v_w_mode,
/* word operand */
w_mode,
/* double word operand */
@@ -2747,10 +2750,10 @@ static const struct dis386 reg_table[][8] = {
{
{ "sldtD", { Sv }, 0 },
{ "strD", { Sv }, 0 },
- { "lldt", { Ew }, 0 },
- { "ltr", { Ew }, 0 },
- { "verr", { Ew }, 0 },
- { "verw", { Ew }, 0 },
+ { "lldtD", { Evw }, 0 },
+ { "ltrD", { Evw }, 0 },
+ { "verrD", { Evw }, 0 },
+ { "verwD", { Evw }, 0 },
{ X86_64_TABLE (X86_64_0F00_REG_6) },
{ Bad_Opcode },
},
@@ -2997,7 +3000,7 @@ static const struct dis386 prefix_table[][4] = {
{ Bad_Opcode },
{ Bad_Opcode },
{ Bad_Opcode },
- { "lkgs", { Ew }, 0 },
+ { "lkgsD", { Evw }, 0 },
},
/* PREFIX_0F01_REG_0_MOD_3_RM_6 */
@@ -11420,12 +11423,18 @@ intel_operand_size (instr_info *ins, int bytemode, int sizeflag)
/* Fall through. */
case v_mode:
case v_swap_mode:
+ case v_w_mode:
case dq_mode:
USED_REX (REX_W);
if (ins->rex & REX_W)
oappend (ins, "QWORD PTR ");
else if (bytemode == dq_mode)
oappend (ins, "DWORD PTR ");
+ else if (bytemode == v_w_mode)
+ {
+ oappend (ins, "WORD PTR ");
+ ins->used_prefixes |= (ins->prefixes & PREFIX_DATA);
+ }
else
{
if (sizeflag & DFLAG)
@@ -11648,6 +11657,7 @@ print_register (instr_info *ins, unsigned int reg, unsigned int rexmask,
names = att_names8;
break;
case w_mode:
+ case v_w_mode:
names = att_names16;
break;
case d_mode:
--
2.31.1
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr
2023-05-26 8:26 ` [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr Haochen Jiang
@ 2023-05-26 8:46 ` Jan Beulich
2023-05-26 8:54 ` Jiang, Haochen
2023-06-01 2:14 ` H.J. Lu
1 sibling, 1 reply; 17+ messages in thread
From: Jan Beulich @ 2023-05-26 8:46 UTC (permalink / raw)
To: Haochen Jiang; +Cc: hjl.tools, jun.zhang, binutils
On 26.05.2023 10:26, Haochen Jiang wrote:
> Currently, for instructions lldt/ltr/verr/verw/lkgs, we are missing
> w suffix for memory operands like sldt/str do. Also the Ew usage is
> not that precise under this scenario. Add Evw to fix this problem.
So why not Sv? It's used solely for segment register moves, sldt, str,
and smsw right now. We're aiming for consistency among all insns
loading / storing segment selector values (and smsw fits that pattern,
but note that lmsw does not), so introducing a new Evw can't be the
solution (or else Sv users would also need switching).
> gas/ChangeLog:
>
> * testsuite/gas/i386/i386.exp: Add LKGS suffix test.
Just as a remark: You'll need to re-base this over what I've committed
half an hour or so ago.
Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr
2023-05-26 8:46 ` Jan Beulich
@ 2023-05-26 8:54 ` Jiang, Haochen
2023-05-26 10:52 ` Jan Beulich
0 siblings, 1 reply; 17+ messages in thread
From: Jiang, Haochen @ 2023-05-26 8:54 UTC (permalink / raw)
To: Beulich, Jan; +Cc: hjl.tools, Zhang, Jun, binutils
> On 26.05.2023 10:26, Haochen Jiang wrote:
> > Currently, for instructions lldt/ltr/verr/verw/lkgs, we are missing w
> > suffix for memory operands like sldt/str do. Also the Ew usage is not
> > that precise under this scenario. Add Evw to fix this problem.
>
> So why not Sv? It's used solely for segment register moves, sldt, str, and
> smsw right now. We're aiming for consistency among all insns loading /
> storing segment selector values (and smsw fits that pattern, but note that
> lmsw does not), so introducing a new Evw can't be the solution (or else Sv
> users would also need switching).
There is a little difference between lldt/ltr/lkgs/verr/verw and sldt/str. We need
to fix the register to 16 bit while sldt/str did not. That is why I am not using Sv. Sv
will emit 'lldt %eax' but not 'lldt %ax' for current testcases and I suppose that is not
desired.
Also since lmsw did not fit the pattern so I did not touch that.
>
> > gas/ChangeLog:
> >
> > * testsuite/gas/i386/i386.exp: Add LKGS suffix test.
>
> Just as a remark: You'll need to re-base this over what I've committed half an
> hour or so ago.
Oh I see that, will rebase to that for v2 patch.
Thx,
Haochen
>
> Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr
2023-05-26 8:54 ` Jiang, Haochen
@ 2023-05-26 10:52 ` Jan Beulich
2023-05-29 2:01 ` Jiang, Haochen
0 siblings, 1 reply; 17+ messages in thread
From: Jan Beulich @ 2023-05-26 10:52 UTC (permalink / raw)
To: Jiang, Haochen; +Cc: hjl.tools, Zhang, Jun, binutils
On 26.05.2023 10:54, Jiang, Haochen wrote:
>> On 26.05.2023 10:26, Haochen Jiang wrote:
>>> Currently, for instructions lldt/ltr/verr/verw/lkgs, we are missing w
>>> suffix for memory operands like sldt/str do. Also the Ew usage is not
>>> that precise under this scenario. Add Evw to fix this problem.
>>
>> So why not Sv? It's used solely for segment register moves, sldt, str, and
>> smsw right now. We're aiming for consistency among all insns loading /
>> storing segment selector values (and smsw fits that pattern, but note that
>> lmsw does not), so introducing a new Evw can't be the solution (or else Sv
>> users would also need switching).
>
> There is a little difference between lldt/ltr/lkgs/verr/verw and sldt/str. We need
> to fix the register to 16 bit while sldt/str did not. That is why I am not using Sv. Sv
> will emit 'lldt %eax' but not 'lldt %ax' for current testcases and I suppose that is not
> desired.
Did you read my reply on one of the "Support Intel FRED LKGS" threads,
which I think I sent before this patch was sent? I do not follow why
you think "we need to fix the register to 16 bit".
Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr
2023-05-26 10:52 ` Jan Beulich
@ 2023-05-29 2:01 ` Jiang, Haochen
2023-05-29 2:08 ` Jiang, Haochen
0 siblings, 1 reply; 17+ messages in thread
From: Jiang, Haochen @ 2023-05-29 2:01 UTC (permalink / raw)
To: Beulich, Jan; +Cc: hjl.tools, Zhang, Jun, binutils
> >>> Currently, for instructions lldt/ltr/verr/verw/lkgs, we are missing
> >>> w suffix for memory operands like sldt/str do. Also the Ew usage is
> >>> not that precise under this scenario. Add Evw to fix this problem.
> >>
> >> So why not Sv? It's used solely for segment register moves, sldt,
> >> str, and smsw right now. We're aiming for consistency among all insns
> >> loading / storing segment selector values (and smsw fits that
> >> pattern, but note that lmsw does not), so introducing a new Evw can't
> >> be the solution (or else Sv users would also need switching).
> >
> > There is a little difference between lldt/ltr/lkgs/verr/verw and
> > sldt/str. We need to fix the register to 16 bit while sldt/str did
> > not. That is why I am not using Sv. Sv will emit 'lldt %eax' but not
> > 'lldt %ax' for current testcases and I suppose that is not desired.
>
> Did you read my reply on one of the "Support Intel FRED LKGS" threads,
> which I think I sent before this patch was sent? I do not follow why you think
> "we need to fix the register to 16 bit".
Maybe I got some wrong understanding on that. It comes from the current testcase.
Trying to clarify that on disassembler.
Let's take lldt as example. Will 0f00d2 emit eax register or ax register for lldt?
If we need a 66 in bytecode to emit ax register as always, Sv+D fits the need. And then
the only thing we might need to do is to adjust the current testcase.
Haochen
>
> Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr
2023-05-29 2:01 ` Jiang, Haochen
@ 2023-05-29 2:08 ` Jiang, Haochen
2023-05-30 8:09 ` Jan Beulich
0 siblings, 1 reply; 17+ messages in thread
From: Jiang, Haochen @ 2023-05-29 2:08 UTC (permalink / raw)
To: Beulich, Jan; +Cc: hjl.tools, Zhang, Jun, binutils
> > >>> Currently, for instructions lldt/ltr/verr/verw/lkgs, we are
> > >>> missing w suffix for memory operands like sldt/str do. Also the Ew
> > >>> usage is not that precise under this scenario. Add Evw to fix this
> problem.
> > >>
> > >> So why not Sv? It's used solely for segment register moves, sldt,
> > >> str, and smsw right now. We're aiming for consistency among all
> > >> insns loading / storing segment selector values (and smsw fits that
> > >> pattern, but note that lmsw does not), so introducing a new Evw
> > >> can't be the solution (or else Sv users would also need switching).
> > >
> > > There is a little difference between lldt/ltr/lkgs/verr/verw and
> > > sldt/str. We need to fix the register to 16 bit while sldt/str did
> > > not. That is why I am not using Sv. Sv will emit 'lldt %eax' but not
> > > 'lldt %ax' for current testcases and I suppose that is not desired.
> >
> > Did you read my reply on one of the "Support Intel FRED LKGS" threads,
> > which I think I sent before this patch was sent? I do not follow why
> > you think "we need to fix the register to 16 bit".
>
> Maybe I got some wrong understanding on that. It comes from the current
> testcase.
> Trying to clarify that on disassembler.
>
> Let's take lldt as example. Will 0f00d2 emit eax register or ax register for lldt?
One thing to add the current behavior for disassembler or trunk is to emit ax
register. Which I mean always is to as always with other instructions.
>
> If we need a 66 in bytecode to emit ax register as always, Sv+D fits the need.
> And then the only thing we might need to do is to adjust the current testcase.
>
> Haochen
>
> >
> > Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr
2023-05-29 2:08 ` Jiang, Haochen
@ 2023-05-30 8:09 ` Jan Beulich
2023-05-31 5:48 ` Jiang, Haochen
0 siblings, 1 reply; 17+ messages in thread
From: Jan Beulich @ 2023-05-30 8:09 UTC (permalink / raw)
To: Jiang, Haochen; +Cc: hjl.tools, Zhang, Jun, binutils
On 29.05.2023 04:08, Jiang, Haochen wrote:
>>>>>> Currently, for instructions lldt/ltr/verr/verw/lkgs, we are
>>>>>> missing w suffix for memory operands like sldt/str do. Also the Ew
>>>>>> usage is not that precise under this scenario. Add Evw to fix this
>> problem.
>>>>>
>>>>> So why not Sv? It's used solely for segment register moves, sldt,
>>>>> str, and smsw right now. We're aiming for consistency among all
>>>>> insns loading / storing segment selector values (and smsw fits that
>>>>> pattern, but note that lmsw does not), so introducing a new Evw
>>>>> can't be the solution (or else Sv users would also need switching).
>>>>
>>>> There is a little difference between lldt/ltr/lkgs/verr/verw and
>>>> sldt/str. We need to fix the register to 16 bit while sldt/str did
>>>> not. That is why I am not using Sv. Sv will emit 'lldt %eax' but not
>>>> 'lldt %ax' for current testcases and I suppose that is not desired.
>>>
>>> Did you read my reply on one of the "Support Intel FRED LKGS" threads,
>>> which I think I sent before this patch was sent? I do not follow why
>>> you think "we need to fix the register to 16 bit".
>>
>> Maybe I got some wrong understanding on that. It comes from the current
>> testcase.
>> Trying to clarify that on disassembler.
>>
>> Let's take lldt as example. Will 0f00d2 emit eax register or ax register for lldt?
>
> One thing to add the current behavior for disassembler or trunk is to emit ax
> register. Which I mean always is to as always with other instructions.
I'm afraid I don't really get what you concern is. Yes, ...
>> If we need a 66 in bytecode to emit ax register as always, Sv+D fits the need.
>> And then the only thing we might need to do is to adjust the current testcase.
... some existing disassembly testcases will likely need adjusting.
Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr
2023-05-30 8:09 ` Jan Beulich
@ 2023-05-31 5:48 ` Jiang, Haochen
2023-05-31 8:43 ` Jan Beulich
0 siblings, 1 reply; 17+ messages in thread
From: Jiang, Haochen @ 2023-05-31 5:48 UTC (permalink / raw)
To: Beulich, Jan, hjl.tools; +Cc: Zhang, Jun, binutils
> >> Maybe I got some wrong understanding on that. It comes from the
> >> current testcase.
> >> Trying to clarify that on disassembler.
> >>
> >> Let's take lldt as example. Will 0f00d2 emit eax register or ax register for
> lldt?
> >
> > One thing to add the current behavior for disassembler or trunk is to
> > emit ax register. Which I mean always is to as always with other instructions.
>
> I'm afraid I don't really get what you concern is. Yes, ...
I mean, for bytecode 0f00d2, should it emit 'lldt %ax' or 'lldt %eax'?
Currently, in the testcase, it emits 'lldt %ax'. I suppose it actually fits documentation
and we should not change it.
BTW, I read SDM today again, for SLDT/STR, they have the exact explanation for
handling of r32/r64.
For STR, we have:
"When the destination operand is a 32-bit register, ..."
"In 64-bit mode, operation is the same. The size of the memory operand is fixed at 16 bits.
In register stores, the 2-byte TR is zero extended if stored to a 64-bit register."
For SLDT, we have:
"Outside IA-32e mode, when the destination operand is a 32-bit register,..."
"In compatibility mode, when the destination operand is a 32-bit register,..."
"In 64-bit mode, using a REX prefix in the form of REX.R permits access to additional
registers (R8-R15). "
But for LLDT/LTR/VERW/VERR, things are different. The operands at least will be fixed at 16 bits
in 64-bit mode.
For LLDT, we have:
"The operand-size attribute has no effect on this instruction.
The LLDT instruction is provided for use in operating-system software; it should not be used
in application programs. This instruction can only be executed in protected mode or 64-bit mode.
In 64-bit mode, the operand size is fixed at 16 bits."
For LTR, we have:
"The operand-size attribute has no effect on this instruction.
In 64-bit mode, the operand size is still fixed at 16 bits."
For VERR/VERW, we have:
"This instruction’s operation is the same in non-64-bit modes and 64-bit mode. The operand size
is fixed at 16 bits."
Therefore, I suppose for VERR/VERW, the 32/64 bit register should never be allowed under any
circumstances. For LLDT/LTR, in 64-bit mode, it should also the same conclusion. In protected mode
and compatibility mode, it is questionable. The current implementation of assembler might need a
fix.
H.J., what is your opinion?
Haochen
>
> >> If we need a 66 in bytecode to emit ax register as always, Sv+D fits the
> need.
> >> And then the only thing we might need to do is to adjust the current
> testcase.
>
> ... some existing disassembly testcases will likely need adjusting.
>
> Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr
2023-05-31 5:48 ` Jiang, Haochen
@ 2023-05-31 8:43 ` Jan Beulich
0 siblings, 0 replies; 17+ messages in thread
From: Jan Beulich @ 2023-05-31 8:43 UTC (permalink / raw)
To: Jiang, Haochen; +Cc: Zhang, Jun, binutils, hjl.tools
On 31.05.2023 07:48, Jiang, Haochen wrote:
>>>> Maybe I got some wrong understanding on that. It comes from the
>>>> current testcase.
>>>> Trying to clarify that on disassembler.
>>>>
>>>> Let's take lldt as example. Will 0f00d2 emit eax register or ax register for
>> lldt?
>>>
>>> One thing to add the current behavior for disassembler or trunk is to
>>> emit ax register. Which I mean always is to as always with other instructions.
>>
>> I'm afraid I don't really get what you concern is. Yes, ...
>
> I mean, for bytecode 0f00d2, should it emit 'lldt %ax' or 'lldt %eax'?
The former in 16-bit code, the latter elsewhere.
> Currently, in the testcase, it emits 'lldt %ax'. I suppose it actually fits documentation
> and we should not change it.
I think we should change it. Expressing operand size by proper GPR
selection is better than emitting (bogus imo) prefixes. Plus, as
said, before, please see the (in principle similar) move to/from
SREG insn handling.
> BTW, I read SDM today again, for SLDT/STR, they have the exact explanation for
> handling of r32/r64.
>
> For STR, we have:
> "When the destination operand is a 32-bit register, ..."
> "In 64-bit mode, operation is the same. The size of the memory operand is fixed at 16 bits.
> In register stores, the 2-byte TR is zero extended if stored to a 64-bit register."
>
> For SLDT, we have:
> "Outside IA-32e mode, when the destination operand is a 32-bit register,..."
> "In compatibility mode, when the destination operand is a 32-bit register,..."
> "In 64-bit mode, using a REX prefix in the form of REX.R permits access to additional
> registers (R8-R15). "
>
> But for LLDT/LTR/VERW/VERR, things are different. The operands at least will be fixed at 16 bits
> in 64-bit mode.
> For LLDT, we have:
> "The operand-size attribute has no effect on this instruction.
> The LLDT instruction is provided for use in operating-system software; it should not be used
> in application programs. This instruction can only be executed in protected mode or 64-bit mode.
> In 64-bit mode, the operand size is fixed at 16 bits."
>
> For LTR, we have:
> "The operand-size attribute has no effect on this instruction.
> In 64-bit mode, the operand size is still fixed at 16 bits."
>
> For VERR/VERW, we have:
> "This instruction’s operation is the same in non-64-bit modes and 64-bit mode. The operand size
> is fixed at 16 bits."
>
> Therefore, I suppose for VERR/VERW, the 32/64 bit register should never be allowed under any
> circumstances. For LLDT/LTR, in 64-bit mode, it should also the same conclusion. In protected mode
> and compatibility mode, it is questionable. The current implementation of assembler might need a
> fix.
Once again, please compare to other insns where we handle things properly.
Moves to/from SREG, as mentioned above, and things like PEXTRW/PINSRW. The
way the SDM puts things isn't always best; the main goal ought to be
consistency within the disassembler (and, just that it's not relevant here,
the assembler as well, of course).
Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr
2023-05-26 8:26 ` [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr Haochen Jiang
2023-05-26 8:46 ` Jan Beulich
@ 2023-06-01 2:14 ` H.J. Lu
1 sibling, 0 replies; 17+ messages in thread
From: H.J. Lu @ 2023-06-01 2:14 UTC (permalink / raw)
To: Haochen Jiang; +Cc: binutils, jbeulich, jun.zhang
On Fri, May 26, 2023 at 1:28 AM Haochen Jiang <haochen.jiang@intel.com> wrote:
>
> Hi Jan,
>
> I am trying to fix the questionable manner with this patch. See if it reaches
> all our expectation.
>
> Thx,
> Haochen
>
> Currently, for instructions lldt/ltr/verr/verw/lkgs, we are missing
> w suffix for memory operands like sldt/str do. Also the Ew usage is
> not that precise under this scenario. Add Evw to fix this problem.
>
> gas/ChangeLog:
>
> * testsuite/gas/i386/i386.exp: Add LKGS suffix test.
> * testsuite/gas/i386/opcode-intel.d: Add ltr, verr, verw.
> * testsuite/gas/i386/opcode-suffix.d: Ditto.
> * testsuite/gas/i386/opcode.d: Ditto.
> * testsuite/gas/i386/opcode.s: Ditto.
> * testsuite/gas/i386/x86-64-lkgs-suffix.d: New test.
> * testsuite/gas/i386/x86-64-lkgs-suffix.s: Ditto.
>
> opcodes/ChangeLog:
>
> * i386-dis.c (Evw): New.
> (v_w_mode): Ditto.
> (lldt, ltr, verr, verw, lkgs): Change from Ew to Evw.
> (intel_operand_size): Handle v_w_mode.
> (print_register): Ditto.
The suffix is needed in AT&T syntax when there is an ambiguity.
In these cases, there is no ambiguity. I don't think we should add
the unnecessary 'w' suffix here.
> ---
> gas/testsuite/gas/i386/i386.exp | 1 +
> gas/testsuite/gas/i386/opcode-intel.d | 3 +++
> gas/testsuite/gas/i386/opcode-suffix.d | 5 ++++-
> gas/testsuite/gas/i386/opcode.d | 3 +++
> gas/testsuite/gas/i386/opcode.s | 4 ++++
> gas/testsuite/gas/i386/x86-64-lkgs-suffix.d | 15 +++++++++++++++
> gas/testsuite/gas/i386/x86-64-lkgs-suffix.s | 7 +++++++
> opcodes/i386-dis.c | 20 +++++++++++++++-----
> 8 files changed, 52 insertions(+), 6 deletions(-)
> create mode 100644 gas/testsuite/gas/i386/x86-64-lkgs-suffix.d
> create mode 100644 gas/testsuite/gas/i386/x86-64-lkgs-suffix.s
>
> diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
> index bce865c83d1..58f32401610 100644
> --- a/gas/testsuite/gas/i386/i386.exp
> +++ b/gas/testsuite/gas/i386/i386.exp
> @@ -1194,6 +1194,7 @@ if [gas_64_check] then {
> run_list_test "x86-64-amx-complex-inval"
> run_dump_test "x86-64-fred"
> run_dump_test "x86-64-lkgs"
> + run_dump_test "x86-64-lkgs-suffix"
> run_list_test "x86-64-lkgs-inval"
> run_dump_test "x86-64-clzero"
> run_dump_test "x86-64-mwaitx-bdver4"
> diff --git a/gas/testsuite/gas/i386/opcode-intel.d b/gas/testsuite/gas/i386/opcode-intel.d
> index 7f641db2892..3a366757a6a 100644
> --- a/gas/testsuite/gas/i386/opcode-intel.d
> +++ b/gas/testsuite/gas/i386/opcode-intel.d
> @@ -589,6 +589,9 @@ Disassembly of section .text:
> *[0-9a-f]+: 85 d8 [ ]*test[ ]+eax,ebx
> *[0-9a-f]+: 85 18 [ ]*test[ ]+(DWORD PTR )?\[eax\],ebx
> *[0-9a-f]+: f1[ ]+int1
> + *[0-9a-f]+: 0f 00 98 90 90 90 90[ ]+ltr[ ]+(WORD PTR )?\[eax-0x6f6f6f70\]
> + *[0-9a-f]+: 0f 00 a0 90 90 90 90[ ]+verr[ ]+(WORD PTR )?\[eax-0x6f6f6f70\]
> + *[0-9a-f]+: 0f 00 a8 90 90 90 90[ ]+verw[ ]+(WORD PTR )?\[eax-0x6f6f6f70\]
> [ ]*[a-f0-9]+: 0f 4a 90 90 90 90 90 cmovp edx,DWORD PTR \[eax-0x6f6f6f70\]
> [ ]*[a-f0-9]+: 0f 4b 90 90 90 90 90 cmovnp edx,DWORD PTR \[eax-0x6f6f6f70\]
> [ ]*[a-f0-9]+: 66 0f 4a 90 90 90 90 90 cmovp dx,WORD PTR \[eax-0x6f6f6f70\]
> diff --git a/gas/testsuite/gas/i386/opcode-suffix.d b/gas/testsuite/gas/i386/opcode-suffix.d
> index 152c3b865a0..fdca16a8a6b 100644
> --- a/gas/testsuite/gas/i386/opcode-suffix.d
> +++ b/gas/testsuite/gas/i386/opcode-suffix.d
> @@ -248,7 +248,7 @@ Disassembly of section .text:
> *[0-9a-f]+: fc[ ]+cld
> *[0-9a-f]+: fd[ ]+std
> *[0-9a-f]+: ff 90 90 90 90 90[ ]+calll[ ]+\*-0x6f6f6f70\(%eax\)
> - *[0-9a-f]+: 0f 00 90 90 90 90 90[ ]+lldt[ ]+-0x6f6f6f70\(%eax\)
> + *[0-9a-f]+: 0f 00 90 90 90 90 90[ ]+lldtw[ ]+-0x6f6f6f70\(%eax\)
> *[0-9a-f]+: 0f 01 90 90 90 90 90[ ]+lgdtl[ ]+-0x6f6f6f70\(%eax\)
> *[0-9a-f]+: 0f 02 90 90 90 90 90[ ]+larl[ ]+-0x6f6f6f70\(%eax\),%edx
> *[0-9a-f]+: 0f 03 90 90 90 90 90[ ]+lsll[ ]+-0x6f6f6f70\(%eax\),%edx
> @@ -589,6 +589,9 @@ Disassembly of section .text:
> *[0-9a-f]+: 85 d8 [ ]*testl[ ]+%ebx,%eax
> *[0-9a-f]+: 85 18 [ ]*testl[ ]+%ebx,\(%eax\)
> *[0-9a-f]+: f1[ ]+int1
> + *[0-9a-f]+: 0f 00 98 90 90 90 90[ ]+ltrw[ ]+-0x6f6f6f70\(%eax\)
> + *[0-9a-f]+: 0f 00 a0 90 90 90 90[ ]+verrw[ ]+-0x6f6f6f70\(%eax\)
> + *[0-9a-f]+: 0f 00 a8 90 90 90 90[ ]+verww[ ]+-0x6f6f6f70\(%eax\)
> [ ]*[a-f0-9]+: 0f 4a 90 90 90 90 90 cmovpl -0x6f6f6f70\(%eax\),%edx
> [ ]*[a-f0-9]+: 0f 4b 90 90 90 90 90 cmovnpl -0x6f6f6f70\(%eax\),%edx
> [ ]*[a-f0-9]+: 66 0f 4a 90 90 90 90 90 cmovpw -0x6f6f6f70\(%eax\),%dx
> diff --git a/gas/testsuite/gas/i386/opcode.d b/gas/testsuite/gas/i386/opcode.d
> index c6ffb018a19..e792962f3c1 100644
> --- a/gas/testsuite/gas/i386/opcode.d
> +++ b/gas/testsuite/gas/i386/opcode.d
> @@ -588,6 +588,9 @@ Disassembly of section .text:
> 9f7: 85 d8 [ ]*test %ebx,%eax
> 9f9: 85 18 [ ]*test %ebx,\(%eax\)
> 9fb: f1 [ ]*int1
> + +[a-f0-9]+: 0f 00 98 90 90 90 90 ltr -0x6f6f6f70\(%eax\)
> + +[a-f0-9]+: 0f 00 a0 90 90 90 90 verr -0x6f6f6f70\(%eax\)
> + +[a-f0-9]+: 0f 00 a8 90 90 90 90 verw -0x6f6f6f70\(%eax\)
> [ ]*[a-f0-9]+: 0f 4a 90 90 90 90 90 cmovp -0x6f6f6f70\(%eax\),%edx
> [ ]*[a-f0-9]+: 0f 4b 90 90 90 90 90 cmovnp -0x6f6f6f70\(%eax\),%edx
> [ ]*[a-f0-9]+: 66 0f 4a 90 90 90 90 90 cmovp -0x6f6f6f70\(%eax\),%dx
> diff --git a/gas/testsuite/gas/i386/opcode.s b/gas/testsuite/gas/i386/opcode.s
> index 000fff3e852..800dc465f70 100644
> --- a/gas/testsuite/gas/i386/opcode.s
> +++ b/gas/testsuite/gas/i386/opcode.s
> @@ -587,6 +587,10 @@ foo:
>
> int1
>
> + ltr 0x90909090(%eax)
> + verr 0x90909090(%eax)
> + verw 0x90909090(%eax)
> +
> cmovpe 0x90909090(%eax),%edx
> cmovpo 0x90909090(%eax),%edx
> cmovpe 0x90909090(%eax),%dx
> diff --git a/gas/testsuite/gas/i386/x86-64-lkgs-suffix.d b/gas/testsuite/gas/i386/x86-64-lkgs-suffix.d
> new file mode 100644
> index 00000000000..5433938f54d
> --- /dev/null
> +++ b/gas/testsuite/gas/i386/x86-64-lkgs-suffix.d
> @@ -0,0 +1,15 @@
> +#as: -J --divide
> +#objdump: -dwMsuffix
> +#name: x86_64 LKGS insns (w/ suffix)
> +#source: x86-64-lkgs.d
> +
> +.*: +file format .*
> +
> +Disassembly of section \.text:
> +
> +0+ <_start>:
> +\s*[a-f0-9]+:\s*f2 42 0f 00 b4 f5 00 00 00 10\s+lkgsw 0x10000000\(%rbp,%r14,8\)
> +\s*[a-f0-9]+:\s*f2 41 0f 00 31\s+lkgsw \(%r9\)
> +\s*[a-f0-9]+:\s*f2 0f 00 b1 fe 00 00 00\s+lkgsw 0xfe\(%rcx\)
> +\s*[a-f0-9]+:\s*f2 0f 00 b2 00 ff ff ff\s+lkgsw -0x100\(%rdx\)
> +#pass
> diff --git a/gas/testsuite/gas/i386/x86-64-lkgs-suffix.s b/gas/testsuite/gas/i386/x86-64-lkgs-suffix.s
> new file mode 100644
> index 00000000000..a8a77e34d0c
> --- /dev/null
> +++ b/gas/testsuite/gas/i386/x86-64-lkgs-suffix.s
> @@ -0,0 +1,7 @@
> + .allow_index_reg
> + .text
> +_start:
> + lkgs 0x10000000(%rbp, %r14, 8)
> + lkgs (%r9)
> + lkgs 254(%rcx)
> + lkgs -256(%rdx)
> diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
> index 07fcf3269f9..1dfa7e2b71c 100644
> --- a/opcodes/i386-dis.c
> +++ b/opcodes/i386-dis.c
> @@ -387,6 +387,7 @@ fetch_error (const instr_info *ins)
> #define Eva { OP_E, va_mode }
> #define Ev_bnd { OP_E, v_bnd_mode }
> #define EvS { OP_E, v_swap_mode }
> +#define Evw { OP_E, v_w_mode }
> #define Ed { OP_E, d_mode }
> #define Edq { OP_E, dq_mode }
> #define Edb { OP_E, db_mode }
> @@ -605,6 +606,8 @@ enum
> v_swap_mode,
> /* operand size depends on address prefix */
> va_mode,
> + /* operand size depends on prefixes but ignore DFLAG */
> + v_w_mode,
> /* word operand */
> w_mode,
> /* double word operand */
> @@ -2747,10 +2750,10 @@ static const struct dis386 reg_table[][8] = {
> {
> { "sldtD", { Sv }, 0 },
> { "strD", { Sv }, 0 },
> - { "lldt", { Ew }, 0 },
> - { "ltr", { Ew }, 0 },
> - { "verr", { Ew }, 0 },
> - { "verw", { Ew }, 0 },
> + { "lldtD", { Evw }, 0 },
> + { "ltrD", { Evw }, 0 },
> + { "verrD", { Evw }, 0 },
> + { "verwD", { Evw }, 0 },
> { X86_64_TABLE (X86_64_0F00_REG_6) },
> { Bad_Opcode },
> },
> @@ -2997,7 +3000,7 @@ static const struct dis386 prefix_table[][4] = {
> { Bad_Opcode },
> { Bad_Opcode },
> { Bad_Opcode },
> - { "lkgs", { Ew }, 0 },
> + { "lkgsD", { Evw }, 0 },
> },
>
> /* PREFIX_0F01_REG_0_MOD_3_RM_6 */
> @@ -11420,12 +11423,18 @@ intel_operand_size (instr_info *ins, int bytemode, int sizeflag)
> /* Fall through. */
> case v_mode:
> case v_swap_mode:
> + case v_w_mode:
> case dq_mode:
> USED_REX (REX_W);
> if (ins->rex & REX_W)
> oappend (ins, "QWORD PTR ");
> else if (bytemode == dq_mode)
> oappend (ins, "DWORD PTR ");
> + else if (bytemode == v_w_mode)
> + {
> + oappend (ins, "WORD PTR ");
> + ins->used_prefixes |= (ins->prefixes & PREFIX_DATA);
> + }
> else
> {
> if (sizeflag & DFLAG)
> @@ -11648,6 +11657,7 @@ print_register (instr_info *ins, unsigned int reg, unsigned int rexmask,
> names = att_names8;
> break;
> case w_mode:
> + case v_w_mode:
> names = att_names16;
> break;
> case d_mode:
> --
> 2.31.1
>
--
H.J.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2023-06-01 2:15 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-22 6:07 [PATCH v2] Support Intel FRED LKGS Zhang, Jun
2023-05-22 9:11 ` Jan Beulich
2023-05-24 6:36 ` Jiang, Haochen
2023-05-25 7:57 ` Jiang, Haochen
2023-05-25 8:42 ` Jan Beulich
2023-05-26 6:50 ` Jiang, Haochen
2023-05-26 7:00 ` Jan Beulich
2023-05-26 8:26 ` [PATCH] x86: Add Evw to emit w suffix for several instrctions for word ptr Haochen Jiang
2023-05-26 8:46 ` Jan Beulich
2023-05-26 8:54 ` Jiang, Haochen
2023-05-26 10:52 ` Jan Beulich
2023-05-29 2:01 ` Jiang, Haochen
2023-05-29 2:08 ` Jiang, Haochen
2023-05-30 8:09 ` Jan Beulich
2023-05-31 5:48 ` Jiang, Haochen
2023-05-31 8:43 ` Jan Beulich
2023-06-01 2:14 ` H.J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).