[committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

Disp16 and Disp32 aren't supported by direct branches in 64-bit mode.
This patch removes them from 64-bit direct branches.

	* opcodes/i386-opc.tbl (call): Remove Disp16|Disp32 from 64-bit
	direct branch.
	(jmp): Likewise.
	* i386-tbl.h: Regenerated.
---
 opcodes/ChangeLog    |  7 +++++++
 opcodes/i386-opc.tbl |  5 +++--
 opcodes/i386-tbl.h   | 19 ++++++++++++++++---
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/opcodes/ChangeLog b/opcodes/ChangeLog
index 99c7a93..8fd1ad3 100644
--- a/opcodes/ChangeLog
+++ b/opcodes/ChangeLog
@@ -1,5 +1,12 @@
 2015-05-11  H.J. Lu  <hongjiu.lu@intel.com>
 
+	* opcodes/i386-opc.tbl (call): Remove Disp16|Disp32 from 64-bit
+	direct branch.
+	(jmp): Likewise.
+	* i386-tbl.h: Regenerated.
+
+2015-05-11  H.J. Lu  <hongjiu.lu@intel.com>
+
 	* configure.ac: Support bfd_iamcu_arch.
 	* disassemble.c (disassembler): Support bfd_iamcu_arch.
 	* i386-gen.c (cpu_flag_init): Add CPU_IAMCU_FLAGS and
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 6edc121..ca629c4 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -319,7 +319,7 @@ shrd, 2, 0xfad, None, 2, Cpu386, Modrm|CheckRegSize|No_bSuf|No_sSuf|No_ldSuf, {
 
 // Control transfer instructions.
 call, 1, 0xe8, None, 1, CpuNo64, JumpDword|DefaultSize|No_bSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Disp16|Disp32 }
-call, 1, 0xe8, None, 1, Cpu64, JumpDword|DefaultSize|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk, { Disp16|Disp32|Disp32S }
+call, 1, 0xe8, None, 1, Cpu64, JumpDword|DefaultSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk, { Disp32S }
 call, 1, 0xff, 0x2, 1, CpuNo64, Modrm|DefaultSize|No_bSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Reg16|Reg32|Word|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|JumpAbsolute }
 call, 1, 0xff, 0x2, 1, Cpu64, Modrm|DefaultSize|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk, { Reg16|Reg64|Word|Qword|Unspecified|BaseIndex|Disp8|Disp32|Disp32S|JumpAbsolute }
 // Intel Syntax
@@ -329,7 +329,8 @@ call, 1, 0xff, 0x3, 1, 0, Modrm|DefaultSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_q
 lcall, 2, 0x9a, None, 1, CpuNo64, JumpInterSegment|DefaultSize|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
 lcall, 1, 0xff, 0x3, 1, 0, Modrm|DefaultSize|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|JumpAbsolute }
 
-jmp, 1, 0xeb, None, 1, 0, Jump|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Disp8|Disp16|Disp32|Disp32S }
+jmp, 1, 0xeb, None, 1, CpuNo64, Jump|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Disp8|Disp16|Disp32|Disp32S }
+jmp, 1, 0xeb, None, 1, Cpu64, Jump|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Disp8|Disp32S }
 jmp, 1, 0xff, 0x4, 1, CpuNo64, Modrm|No_bSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Reg16|Reg32|Word|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|JumpAbsolute }
 jmp, 1, 0xff, 0x4, 1, Cpu64, Modrm|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk, { Reg16|Reg64|Word|Qword|Unspecified|BaseIndex|Disp8|Disp32|Disp32S|JumpAbsolute }
 // Intel Syntax.
diff --git a/opcodes/i386-tbl.h b/opcodes/i386-tbl.h
index a722127..a6115ec 100644
--- a/opcodes/i386-tbl.h
+++ b/opcodes/i386-tbl.h
@@ -3188,12 +3188,12 @@ const insn_template i386_optab[] =
         0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
         0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
         0, 0, 1, 0, 0 } },
-    { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0,
+    { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1,
       1, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0,
       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
       0, 0 },
     { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
   { "call", 1, 0xff, 0x2, 1,
     { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
@@ -3284,7 +3284,7 @@ const insn_template i386_optab[] =
         0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
         0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
         0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-        0, 0, 0, 0, 0 } },
+        0, 0, 0, 1, 0 } },
     { 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
       1, 1, 1, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
@@ -3292,6 +3292,19 @@ const insn_template i386_optab[] =
     { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
+  { "jmp", 1, 0xeb, None, 1,
+    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 1, 0, 0 } },
+    { 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
+      1, 1, 1, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+      0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+      0, 0 },
+    { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
   { "jmp", 1, 0xff, 0x4, 1,
     { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
         0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-- 
1.9.3

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Jan Beulich]

>>> On 11.05.15 at 23:23, <hongjiu.lu@intel.com> wrote:
> Disp16 and Disp32 aren't supported by direct branches in 64-bit mode.
> This patch removes them from 64-bit direct branches.

See the recent discussion regarding callw - these can certainly have
16-bit displacements on AMD CPUs. And while disassembly may just
get "disturbed" by getting this wrong, assembly will produce bad
code if you don't account for both cases (or refuse to assemble
such mnemonics if they would require size overrides to be added).

Apart from that I wonder why you do this for CALL and JMP, but not
for Jcc, JCXZ, JRCXZ, LOOP, and LOOPcc.

But first of all - please don't bias x86 binutils towards only supporting
Intel hardware.

Jan

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 3:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 11.05.15 at 23:23, <hongjiu.lu@intel.com> wrote:
>> Disp16 and Disp32 aren't supported by direct branches in 64-bit mode.
>> This patch removes them from 64-bit direct branches.
>
> See the recent discussion regarding callw - these can certainly have
> 16-bit displacements on AMD CPUs. And while disassembly may just
> get "disturbed" by getting this wrong, assembly will produce bad
> code if you don't account for both cases (or refuse to assemble
> such mnemonics if they would require size overrides to be added).
>
> Apart from that I wonder why you do this for CALL and JMP, but not
> for Jcc, JCXZ, JRCXZ, LOOP, and LOOPcc.
>
> But first of all - please don't bias x86 binutils towards only supporting
> Intel hardware.

Can you generate call/jmp with 16-bit displacement in 64-bit mode?


-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Jan Beulich]

>>> On 12.05.15 at 13:54, <hjl.tools@gmail.com> wrote:
> On Tue, May 12, 2015 at 3:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 11.05.15 at 23:23, <hongjiu.lu@intel.com> wrote:
>>> Disp16 and Disp32 aren't supported by direct branches in 64-bit mode.
>>> This patch removes them from 64-bit direct branches.
>>
>> See the recent discussion regarding callw - these can certainly have
>> 16-bit displacements on AMD CPUs. And while disassembly may just
>> get "disturbed" by getting this wrong, assembly will produce bad
>> code if you don't account for both cases (or refuse to assemble
>> such mnemonics if they would require size overrides to be added).
>>
>> Apart from that I wonder why you do this for CALL and JMP, but not
>> for Jcc, JCXZ, JRCXZ, LOOP, and LOOPcc.
>>
>> But first of all - please don't bias x86 binutils towards only supporting
>> Intel hardware.
> 
> Can you generate call/jmp with 16-bit displacement in 64-bit mode?

Didn't check whether there is a mechanism currently; of course I
would expect "data16 jmp <label>" to do precisely that.

Jan

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 5:20 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 12.05.15 at 13:54, <hjl.tools@gmail.com> wrote:
>> On Tue, May 12, 2015 at 3:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 11.05.15 at 23:23, <hongjiu.lu@intel.com> wrote:
>>>> Disp16 and Disp32 aren't supported by direct branches in 64-bit mode.
>>>> This patch removes them from 64-bit direct branches.
>>>
>>> See the recent discussion regarding callw - these can certainly have
>>> 16-bit displacements on AMD CPUs. And while disassembly may just
>>> get "disturbed" by getting this wrong, assembly will produce bad
>>> code if you don't account for both cases (or refuse to assemble
>>> such mnemonics if they would require size overrides to be added).
>>>
>>> Apart from that I wonder why you do this for CALL and JMP, but not
>>> for Jcc, JCXZ, JRCXZ, LOOP, and LOOPcc.
>>>
>>> But first of all - please don't bias x86 binutils towards only supporting
>>> Intel hardware.
>>
>> Can you generate call/jmp with 16-bit displacement in 64-bit mode?
>
> Didn't check whether there is a mechanism currently; of course I
> would expect "data16 jmp <label>" to do precisely that.

Does my change generate different binary now?

-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Jan Beulich]

>>> On 12.05.15 at 14:37, <hjl.tools@gmail.com> wrote:
> On Tue, May 12, 2015 at 5:20 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 12.05.15 at 13:54, <hjl.tools@gmail.com> wrote:
>>> On Tue, May 12, 2015 at 3:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 11.05.15 at 23:23, <hongjiu.lu@intel.com> wrote:
>>>>> Disp16 and Disp32 aren't supported by direct branches in 64-bit mode.
>>>>> This patch removes them from 64-bit direct branches.
>>>>
>>>> See the recent discussion regarding callw - these can certainly have
>>>> 16-bit displacements on AMD CPUs. And while disassembly may just
>>>> get "disturbed" by getting this wrong, assembly will produce bad
>>>> code if you don't account for both cases (or refuse to assemble
>>>> such mnemonics if they would require size overrides to be added).
>>>>
>>>> Apart from that I wonder why you do this for CALL and JMP, but not
>>>> for Jcc, JCXZ, JRCXZ, LOOP, and LOOPcc.
>>>>
>>>> But first of all - please don't bias x86 binutils towards only supporting
>>>> Intel hardware.
>>>
>>> Can you generate call/jmp with 16-bit displacement in 64-bit mode?
>>
>> Didn't check whether there is a mechanism currently; of course I
>> would expect "data16 jmp <label>" to do precisely that.
> 
> Does my change generate different binary now?

I suppose so (but I don't have the time to check right now). What
I did check is that what I suggested above indeed works with 2.25,
including the creation of 16-bit PC-relative relocations.

Jan

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 6:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 12.05.15 at 14:37, <hjl.tools@gmail.com> wrote:
>> On Tue, May 12, 2015 at 5:20 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 12.05.15 at 13:54, <hjl.tools@gmail.com> wrote:
>>>> On Tue, May 12, 2015 at 3:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>> On 11.05.15 at 23:23, <hongjiu.lu@intel.com> wrote:
>>>>>> Disp16 and Disp32 aren't supported by direct branches in 64-bit mode.
>>>>>> This patch removes them from 64-bit direct branches.
>>>>>
>>>>> See the recent discussion regarding callw - these can certainly have
>>>>> 16-bit displacements on AMD CPUs. And while disassembly may just
>>>>> get "disturbed" by getting this wrong, assembly will produce bad
>>>>> code if you don't account for both cases (or refuse to assemble
>>>>> such mnemonics if they would require size overrides to be added).
>>>>>
>>>>> Apart from that I wonder why you do this for CALL and JMP, but not
>>>>> for Jcc, JCXZ, JRCXZ, LOOP, and LOOPcc.
>>>>>
>>>>> But first of all - please don't bias x86 binutils towards only supporting
>>>>> Intel hardware.
>>>>
>>>> Can you generate call/jmp with 16-bit displacement in 64-bit mode?
>>>
>>> Didn't check whether there is a mechanism currently; of course I
>>> would expect "data16 jmp <label>" to do precisely that.
>>
>> Does my change generate different binary now?
>
> I suppose so (but I don't have the time to check right now). What
> I did check is that what I suggested above indeed works with 2.25,
> including the creation of 16-bit PC-relative relocations.
>
> Jan
>

This is what I got now:

[hjl@gnu-6 tmp]$  cat x.s
.text
data16 jmp foo
bar:
mov %eax,%edx
[hjl@gnu-6 tmp]$ gcc -c x.s
[hjl@gnu-6 tmp]$ objdump -dwr x.o

x.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <bar-0x4>:
   0: 66 e9 00 00 89 c2     data16 jmpq ffffffffc2890006
<bar+0xffffffffc2890002> 2: R_X86_64_PC16 foo-0x2

0000000000000004 <bar>:
   4: 89 c2                 mov    %eax,%edx
[hjl@gnu-6 tmp]$

Is that the same as what you got with binutils 2.25?

-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Michael Matz]

Hi,

On Tue, 12 May 2015, H.J. Lu wrote:

> This is what I got now:
> 
> [hjl@gnu-6 tmp]$  cat x.s
> .text
> data16 jmp foo
> bar:
> mov %eax,%edx
> [hjl@gnu-6 tmp]$ gcc -c x.s
> [hjl@gnu-6 tmp]$ objdump -dwr x.o
> 
> x.o:     file format elf64-x86-64
> 
> 
> Disassembly of section .text:
> 
> 0000000000000000 <bar-0x4>:
>    0: 66 e9 00 00 89 c2     data16 jmpq ffffffffc2890006
> <bar+0xffffffffc2890002> 2: R_X86_64_PC16 foo-0x2
> 
> 0000000000000004 <bar>:
>    4: 89 c2                 mov    %eax,%edx
> [hjl@gnu-6 tmp]$
> 
> Is that the same as what you got with binutils 2.25?

This is with 2.23, so your patch would cause a regression:

x.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <bar-0x4>:
   0:   66 e9 00 00             jmpw   4 <bar>
                        2: R_X86_64_PC16        foo-0x2

0000000000000004 <bar>:
   4:   89 c2                   mov    %eax,%edx


Ciao,
Michael.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 6:49 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 12 May 2015, H.J. Lu wrote:
>
>> This is what I got now:
>>
>> [hjl@gnu-6 tmp]$  cat x.s
>> .text
>> data16 jmp foo
>> bar:
>> mov %eax,%edx
>> [hjl@gnu-6 tmp]$ gcc -c x.s
>> [hjl@gnu-6 tmp]$ objdump -dwr x.o
>>
>> x.o:     file format elf64-x86-64
>>
>>
>> Disassembly of section .text:
>>
>> 0000000000000000 <bar-0x4>:
>>    0: 66 e9 00 00 89 c2     data16 jmpq ffffffffc2890006
>> <bar+0xffffffffc2890002> 2: R_X86_64_PC16 foo-0x2
>>
>> 0000000000000004 <bar>:
>>    4: 89 c2                 mov    %eax,%edx
>> [hjl@gnu-6 tmp]$
>>
>> Is that the same as what you got with binutils 2.25?
>
> This is with 2.23, so your patch would cause a regression:

1. This happened before 20140923.
2. Can you speculate what

" jmpw   4"

does?


> x.o:     file format elf64-x86-64
>
>
> Disassembly of section .text:
>
> 0000000000000000 <bar-0x4>:
>    0:   66 e9 00 00             jmpw   4 <bar>
>                         2: R_X86_64_PC16        foo-0x2
>
> 0000000000000004 <bar>:
>    4:   89 c2                   mov    %eax,%edx
>
>
> Ciao,
> Michael.



-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Michael Matz]

Hi,

On Tue, 12 May 2015, H.J. Lu wrote:

> > This is with 2.23, so your patch would cause a regression:
> 
> 1. This happened before 20140923.

Same with current 2.25-branch.

> 2. Can you speculate what
> 
> " jmpw   4"
> 
> does?

It should do a jump to $nextip+offset, of course, just like a 32bit 
jump.  The disassembly is correct, because with a zero offset, that's 
indeed '4'.


Ciao,
Michael.

> > x.o:     file format elf64-x86-64
> >
> >
> > Disassembly of section .text:
> >
> > 0000000000000000 <bar-0x4>:
> >    0:   66 e9 00 00             jmpw   4 <bar>
> >                         2: R_X86_64_PC16        foo-0x2
> >
> > 0000000000000004 <bar>:
> >    4:   89 c2                   mov    %eax,%edx

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 7:31 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 12 May 2015, H.J. Lu wrote:
>
>> > This is with 2.23, so your patch would cause a regression:
>>
>> 1. This happened before 20140923.
>
> Same with current 2.25-branch.
>
>> 2. Can you speculate what
>>
>> " jmpw   4"
>>
>> does?
>
> It should do a jump to $nextip+offset, of course, just like a 32bit
> jump.  The disassembly is correct, because with a zero offset, that's
> indeed '4'.
>

I thought it did jump to "(nextip + offset) & 0xffff" on AMD.  Can you
verify if it is true?


-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Jan Beulich]

>>> On 12.05.15 at 15:37, <hjl.tools@gmail.com> wrote:
> On Tue, May 12, 2015 at 6:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 12.05.15 at 14:37, <hjl.tools@gmail.com> wrote:
>>> On Tue, May 12, 2015 at 5:20 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 12.05.15 at 13:54, <hjl.tools@gmail.com> wrote:
>>>>> On Tue, May 12, 2015 at 3:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>>> On 11.05.15 at 23:23, <hongjiu.lu@intel.com> wrote:
>>>>>>> Disp16 and Disp32 aren't supported by direct branches in 64-bit mode.
>>>>>>> This patch removes them from 64-bit direct branches.
>>>>>>
>>>>>> See the recent discussion regarding callw - these can certainly have
>>>>>> 16-bit displacements on AMD CPUs. And while disassembly may just
>>>>>> get "disturbed" by getting this wrong, assembly will produce bad
>>>>>> code if you don't account for both cases (or refuse to assemble
>>>>>> such mnemonics if they would require size overrides to be added).
>>>>>>
>>>>>> Apart from that I wonder why you do this for CALL and JMP, but not
>>>>>> for Jcc, JCXZ, JRCXZ, LOOP, and LOOPcc.
>>>>>>
>>>>>> But first of all - please don't bias x86 binutils towards only supporting
>>>>>> Intel hardware.
>>>>>
>>>>> Can you generate call/jmp with 16-bit displacement in 64-bit mode?
>>>>
>>>> Didn't check whether there is a mechanism currently; of course I
>>>> would expect "data16 jmp <label>" to do precisely that.
>>>
>>> Does my change generate different binary now?
>>
>> I suppose so (but I don't have the time to check right now). What
>> I did check is that what I suggested above indeed works with 2.25,
>> including the creation of 16-bit PC-relative relocations.
>>
>> Jan
>>
> 
> This is what I got now:
> 
> [hjl@gnu-6 tmp]$  cat x.s
> .text
> data16 jmp foo
> bar:
> mov %eax,%edx
> [hjl@gnu-6 tmp]$ gcc -c x.s
> [hjl@gnu-6 tmp]$ objdump -dwr x.o
> 
> x.o:     file format elf64-x86-64
> 
> 
> Disassembly of section .text:
> 
> 0000000000000000 <bar-0x4>:
>    0: 66 e9 00 00 89 c2     data16 jmpq ffffffffc2890006
> <bar+0xffffffffc2890002> 2: R_X86_64_PC16 foo-0x2
> 
> 0000000000000004 <bar>:
>    4: 89 c2                 mov    %eax,%edx
> [hjl@gnu-6 tmp]$
> 
> Is that the same as what you got with binutils 2.25?

Yes. But then what was the point of you ripping out Disp16?

Jan

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 7:59 AM, Jan Beulich <JBeulich@suse.com> wrote:
> Yes. But then what was the point of you ripping out Disp16?

I removed it since it doesn't jump to the target.  Can you verify
that it does jump to "(nextip + disp16) & 0xffff, not jump to
"(nextip + disp16)"?


-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Jan Beulich]

>>> On 12.05.15 at 17:03, <hjl.tools@gmail.com> wrote:
> On Tue, May 12, 2015 at 7:59 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> Yes. But then what was the point of you ripping out Disp16?
> 
> I removed it since it doesn't jump to the target.  Can you verify
> that it does jump to "(nextip + disp16) & 0xffff, not jump to
> "(nextip + disp16)"?

Yes - see the gdb output I provided yesterday.

Jan

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 8:09 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 12.05.15 at 17:03, <hjl.tools@gmail.com> wrote:
>> On Tue, May 12, 2015 at 7:59 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> Yes. But then what was the point of you ripping out Disp16?
>>
>> I removed it since it doesn't jump to the target.  Can you verify
>> that it does jump to "(nextip + disp16) & 0xffff, not jump to
>> "(nextip + disp16)"?
>
> Yes - see the gdb output I provided yesterday.
>

Does it mean it is wrong to display

 0:   66 e9 00 00             jmpw   4 <bar>
                        2: R_X86_64_PC16        foo-0x2

0000000000000004 <bar>:
   4:   89 c2                   mov    %eax,%edx



-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Michael Matz]

Hi,

On Tue, 12 May 2015, H.J. Lu wrote:

> >> 2. Can you speculate what
> >>
> >> " jmpw   4"
> >>
> >> does?
> >
> > It should do a jump to $nextip+offset, of course, just like a 32bit
> > jump.  The disassembly is correct, because with a zero offset, that's
> > indeed '4'.
> 
> I thought it did jump to "(nextip + offset) & 0xffff" on AMD.  Can you 
> verify if it is true?

Sorry, yes, this is true, the 16bit operand size prefix truncates RIP to 
16 bit.  Nevertheless it's a valid instruction and works as documented.


Ciao,
Michael.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Jan Beulich]

>>> On 12.05.15 at 17:11, <hjl.tools@gmail.com> wrote:
> On Tue, May 12, 2015 at 8:09 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 12.05.15 at 17:03, <hjl.tools@gmail.com> wrote:
>>> On Tue, May 12, 2015 at 7:59 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> Yes. But then what was the point of you ripping out Disp16?
>>>
>>> I removed it since it doesn't jump to the target.  Can you verify
>>> that it does jump to "(nextip + disp16) & 0xffff, not jump to
>>> "(nextip + disp16)"?
>>
>> Yes - see the gdb output I provided yesterday.
>>
> 
> Does it mean it is wrong to display
> 
>  0:   66 e9 00 00             jmpw   4 <bar>
>                         2: R_X86_64_PC16        foo-0x2
> 
> 0000000000000004 <bar>:
>    4:   89 c2                   mov    %eax,%edx

I don't think so - this looks quite okay. It would become more of an
issue when looking at other than relocatable object files (namely
when their image base is non-zero), or ones with .text exceeding
32k.

Jan

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 8:14 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 12 May 2015, H.J. Lu wrote:
>
>> >> 2. Can you speculate what
>> >>
>> >> " jmpw   4"
>> >>
>> >> does?
>> >
>> > It should do a jump to $nextip+offset, of course, just like a 32bit
>> > jump.  The disassembly is correct, because with a zero offset, that's
>> > indeed '4'.
>>
>> I thought it did jump to "(nextip + offset) & 0xffff" on AMD.  Can you
>> verify if it is true?
>
> Sorry, yes, this is true, the 16bit operand size prefix truncates RIP to
> 16 bit.  Nevertheless it's a valid instruction and works as documented.

It doesn't work on Intel processors.  Can you show me a real usage
for this?


-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Michael Matz]

Hi,

On Tue, 12 May 2015, H.J. Lu wrote:

> >> I thought it did jump to "(nextip + offset) & 0xffff" on AMD.  Can 
> >> you verify if it is true?
> >
> > Sorry, yes, this is true, the 16bit operand size prefix truncates RIP 
> > to 16 bit.  Nevertheless it's a valid instruction and works as 
> > documented.
> 
> It doesn't work on Intel processors.  Can you show me a real usage for 
> this?

Why should I?  Obviously in linux there are no uses, but perhaps in BIOS 
or boot loader code, or micro-OSes and the like.  Can you instead show me 
why you want to remove support for it?


Ciao,
Michael.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Michael Matz]

Hi,

On Tue, 12 May 2015, Jan Beulich wrote:

> I don't think so - this looks quite okay. It would become more of an 
> issue when looking at other than relocatable object files (namely when 
> their image base is non-zero), or ones with .text exceeding 32k.

Actually also that one is correctly printed I think (from a hello world 
main, where I added a jmprel16 +0):

000000000040055c <main>:
  40055c:       55                      push   %rbp
  40055d:       48 89 e5                mov    %rsp,%rbp
  400560:       48 83 ec 30             sub    $0x30,%rsp
  400564:       c6 45 d1 00             movb   $0x0,-0x2f(%rbp)
  400568:       c6 45 d0 61             movb   $0x61,-0x30(%rbp)
  40056c:       48 8d 45 d0             lea    -0x30(%rbp),%rax
  400570:       48 89 c2                mov    %rax,%rdx
  400573:       be 44 06 40 00          mov    $0x400644,%esi
  400578:       66 e9 00 00             jmpw   57c <_init-0x3ffe8c>

000000000040057c <next>:
  40057c:       bf 52 06 40 00          mov    $0x400652,%edi
  ...

It shows that rip is going to be truncated.


Ciao,
Michael.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 8:37 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 12 May 2015, Jan Beulich wrote:
>
>> I don't think so - this looks quite okay. It would become more of an
>> issue when looking at other than relocatable object files (namely when
>> their image base is non-zero), or ones with .text exceeding 32k.
>
> Actually also that one is correctly printed I think (from a hello world
> main, where I added a jmprel16 +0):
>
> 000000000040055c <main>:
>   40055c:       55                      push   %rbp
>   40055d:       48 89 e5                mov    %rsp,%rbp
>   400560:       48 83 ec 30             sub    $0x30,%rsp
>   400564:       c6 45 d1 00             movb   $0x0,-0x2f(%rbp)
>   400568:       c6 45 d0 61             movb   $0x61,-0x30(%rbp)
>   40056c:       48 8d 45 d0             lea    -0x30(%rbp),%rax
>   400570:       48 89 c2                mov    %rax,%rdx
>   400573:       be 44 06 40 00          mov    $0x400644,%esi
>   400578:       66 e9 00 00             jmpw   57c <_init-0x3ffe8c>
>
> 000000000040057c <next>:
>   40057c:       bf 52 06 40 00          mov    $0x400652,%edi
>   ...
>
> It shows that rip is going to be truncated.
>

This is the same issue as

https://sourceware.org/bugzilla/show_bug.cgi?id=18386

On Intel processors, 0x66 prefix before direct 32-bit unconditional
call/jmp is ignored.  Whatever we do is wrong on AMD or Intel
processors.


-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Michael Matz]

Hi,

On Tue, 12 May 2015, H.J. Lu wrote:

> > Actually also that one is correctly printed I think (from a hello world
> > main, where I added a jmprel16 +0):
> >
> > 000000000040055c <main>:
> >   40055c:       55                      push   %rbp
> >   40055d:       48 89 e5                mov    %rsp,%rbp
> >   400560:       48 83 ec 30             sub    $0x30,%rsp
> >   400564:       c6 45 d1 00             movb   $0x0,-0x2f(%rbp)
> >   400568:       c6 45 d0 61             movb   $0x61,-0x30(%rbp)
> >   40056c:       48 8d 45 d0             lea    -0x30(%rbp),%rax
> >   400570:       48 89 c2                mov    %rax,%rdx
> >   400573:       be 44 06 40 00          mov    $0x400644,%esi
> >   400578:       66 e9 00 00             jmpw   57c <_init-0x3ffe8c>
> >
> > 000000000040057c <next>:
> >   40057c:       bf 52 06 40 00          mov    $0x400652,%edi
> >   ...
> >
> > It shows that rip is going to be truncated.
> >
> 
> This is the same issue as
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=18386
> 
> On Intel processors, 0x66 prefix before direct 32-bit unconditional
> call/jmp is ignored.  Whatever we do is wrong on AMD or Intel
> processors.

Well, in that case I'd say the correct thing to do is to _not_ do any 
change, but rather let bintils work like it always did and resolve the 
above bug report as WONTFIX (or unfixable or something).


Ciao,
Michael.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 8:47 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 12 May 2015, H.J. Lu wrote:
>
>> > Actually also that one is correctly printed I think (from a hello world
>> > main, where I added a jmprel16 +0):
>> >
>> > 000000000040055c <main>:
>> >   40055c:       55                      push   %rbp
>> >   40055d:       48 89 e5                mov    %rsp,%rbp
>> >   400560:       48 83 ec 30             sub    $0x30,%rsp
>> >   400564:       c6 45 d1 00             movb   $0x0,-0x2f(%rbp)
>> >   400568:       c6 45 d0 61             movb   $0x61,-0x30(%rbp)
>> >   40056c:       48 8d 45 d0             lea    -0x30(%rbp),%rax
>> >   400570:       48 89 c2                mov    %rax,%rdx
>> >   400573:       be 44 06 40 00          mov    $0x400644,%esi
>> >   400578:       66 e9 00 00             jmpw   57c <_init-0x3ffe8c>
>> >
>> > 000000000040057c <next>:
>> >   40057c:       bf 52 06 40 00          mov    $0x400652,%edi
>> >   ...
>> >
>> > It shows that rip is going to be truncated.
>> >
>>
>> This is the same issue as
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=18386
>>
>> On Intel processors, 0x66 prefix before direct 32-bit unconditional
>> call/jmp is ignored.  Whatever we do is wrong on AMD or Intel
>> processors.
>
> Well, in that case I'd say the correct thing to do is to _not_ do any

This is NO correct thing to do.

> change, but rather let bintils work like it always did and resolve the
> above bug report as WONTFIX (or unfixable or something).
>
>
> Ciao,
> Michael.



-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Michael Matz]

Hi,

On Tue, 12 May 2015, H.J. Lu wrote:

> On Tue, May 12, 2015 at 8:47 AM, Michael Matz <matz@suse.de> wrote:
> > Hi,
> >
> > On Tue, 12 May 2015, H.J. Lu wrote:
> >
> >> > Actually also that one is correctly printed I think (from a hello world
> >> > main, where I added a jmprel16 +0):
> >> >
> >> > 000000000040055c <main>:
> >> >   40055c:       55                      push   %rbp
> >> >   40055d:       48 89 e5                mov    %rsp,%rbp
> >> >   400560:       48 83 ec 30             sub    $0x30,%rsp
> >> >   400564:       c6 45 d1 00             movb   $0x0,-0x2f(%rbp)
> >> >   400568:       c6 45 d0 61             movb   $0x61,-0x30(%rbp)
> >> >   40056c:       48 8d 45 d0             lea    -0x30(%rbp),%rax
> >> >   400570:       48 89 c2                mov    %rax,%rdx
> >> >   400573:       be 44 06 40 00          mov    $0x400644,%esi
> >> >   400578:       66 e9 00 00             jmpw   57c <_init-0x3ffe8c>
> >> >
> >> > 000000000040057c <next>:
> >> >   40057c:       bf 52 06 40 00          mov    $0x400652,%edi
> >> >   ...
> >> >
> >> > It shows that rip is going to be truncated.
> >> >
> >>
> >> This is the same issue as
> >>
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=18386
> >>
> >> On Intel processors, 0x66 prefix before direct 32-bit unconditional
> >> call/jmp is ignored.  Whatever we do is wrong on AMD or Intel
> >> processors.
> >
> > Well, in that case I'd say the correct thing to do is to _not_ do any
> 
> This is NO correct thing to do.

Well, what do you suggest?  Your change is clearly wrong as well.


Ciao,
Michael.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 9:03 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 12 May 2015, H.J. Lu wrote:
>
>> On Tue, May 12, 2015 at 8:47 AM, Michael Matz <matz@suse.de> wrote:
>> > Hi,
>> >
>> > On Tue, 12 May 2015, H.J. Lu wrote:
>> >
>> >> > Actually also that one is correctly printed I think (from a hello world
>> >> > main, where I added a jmprel16 +0):
>> >> >
>> >> > 000000000040055c <main>:
>> >> >   40055c:       55                      push   %rbp
>> >> >   40055d:       48 89 e5                mov    %rsp,%rbp
>> >> >   400560:       48 83 ec 30             sub    $0x30,%rsp
>> >> >   400564:       c6 45 d1 00             movb   $0x0,-0x2f(%rbp)
>> >> >   400568:       c6 45 d0 61             movb   $0x61,-0x30(%rbp)
>> >> >   40056c:       48 8d 45 d0             lea    -0x30(%rbp),%rax
>> >> >   400570:       48 89 c2                mov    %rax,%rdx
>> >> >   400573:       be 44 06 40 00          mov    $0x400644,%esi
>> >> >   400578:       66 e9 00 00             jmpw   57c <_init-0x3ffe8c>
>> >> >
>> >> > 000000000040057c <next>:
>> >> >   40057c:       bf 52 06 40 00          mov    $0x400652,%edi
>> >> >   ...
>> >> >
>> >> > It shows that rip is going to be truncated.
>> >> >
>> >>
>> >> This is the same issue as
>> >>
>> >> https://sourceware.org/bugzilla/show_bug.cgi?id=18386
>> >>
>> >> On Intel processors, 0x66 prefix before direct 32-bit unconditional
>> >> call/jmp is ignored.  Whatever we do is wrong on AMD or Intel
>> >> processors.
>> >
>> > Well, in that case I'd say the correct thing to do is to _not_ do any
>>
>> This is NO correct thing to do.
>
> Well, what do you suggest?  Your change is clearly wrong as well.

I won't call it wrong since it implies there is a right.  Given that

0x66 jmp/call rel32

works on Intel processors and crashes on AMD processors.
I will keep my change in unlessl someone can show a real usage of

066 jmp/call rel16

on AMD processors.


-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Jan Beulich]

>>> On 12.05.15 at 18:08, <hjl.tools@gmail.com> wrote:
> On Tue, May 12, 2015 at 9:03 AM, Michael Matz <matz@suse.de> wrote:
>> Hi,
>>
>> On Tue, 12 May 2015, H.J. Lu wrote:
>>
>>> On Tue, May 12, 2015 at 8:47 AM, Michael Matz <matz@suse.de> wrote:
>>> > Hi,
>>> >
>>> > On Tue, 12 May 2015, H.J. Lu wrote:
>>> >
>>> >> > Actually also that one is correctly printed I think (from a hello world
>>> >> > main, where I added a jmprel16 +0):
>>> >> >
>>> >> > 000000000040055c <main>:
>>> >> >   40055c:       55                      push   %rbp
>>> >> >   40055d:       48 89 e5                mov    %rsp,%rbp
>>> >> >   400560:       48 83 ec 30             sub    $0x30,%rsp
>>> >> >   400564:       c6 45 d1 00             movb   $0x0,-0x2f(%rbp)
>>> >> >   400568:       c6 45 d0 61             movb   $0x61,-0x30(%rbp)
>>> >> >   40056c:       48 8d 45 d0             lea    -0x30(%rbp),%rax
>>> >> >   400570:       48 89 c2                mov    %rax,%rdx
>>> >> >   400573:       be 44 06 40 00          mov    $0x400644,%esi
>>> >> >   400578:       66 e9 00 00             jmpw   57c <_init-0x3ffe8c>
>>> >> >
>>> >> > 000000000040057c <next>:
>>> >> >   40057c:       bf 52 06 40 00          mov    $0x400652,%edi
>>> >> >   ...
>>> >> >
>>> >> > It shows that rip is going to be truncated.
>>> >> >
>>> >>
>>> >> This is the same issue as
>>> >>
>>> >> https://sourceware.org/bugzilla/show_bug.cgi?id=18386 
>>> >>
>>> >> On Intel processors, 0x66 prefix before direct 32-bit unconditional
>>> >> call/jmp is ignored.  Whatever we do is wrong on AMD or Intel
>>> >> processors.
>>> >
>>> > Well, in that case I'd say the correct thing to do is to _not_ do any
>>>
>>> This is NO correct thing to do.
>>
>> Well, what do you suggest?  Your change is clearly wrong as well.
> 
> I won't call it wrong since it implies there is a right.  Given that
> 
> 0x66 jmp/call rel32
> 
> works on Intel processors and crashes on AMD processors.

What _works_ on Intel processors is secondary here. Fact is that
the x86-64 design came from AMD, and hence Intel CPUs doing
things differently than AMD's is - be honest - a flaw. The more
that by analogy with 32-bit mode, an operand size prefix on
branches ought to truncate rIP. Plus (other than my own testing
says) you seem to suggest that this isn't even consistent on Intel
CPUs, as you specifically say "unconditional" above and you also
only changed those.

> I will keep my change in unlessl someone can show a real usage of
> 
> 066 jmp/call rel16
> 
> on AMD processors.

That's the wrong position, you have to show that the change is
useful - I certainly can't see why you'd need the operand size
prefix when (on Intel CPUs) it has no effect whatsoever.
Together with it not being generally usable (due to the vendor
differences), I view the change as pointless _and_ breaking
compatibility (i.e. both by themselves a reason to revert).

Jan

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Tue, May 12, 2015 at 11:18 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 12.05.15 at 18:08, <hjl.tools@gmail.com> wrote:
>> On Tue, May 12, 2015 at 9:03 AM, Michael Matz <matz@suse.de> wrote:
>>> Hi,
>>>
>>> On Tue, 12 May 2015, H.J. Lu wrote:
>>>
>>>> On Tue, May 12, 2015 at 8:47 AM, Michael Matz <matz@suse.de> wrote:
>>>> > Hi,
>>>> >
>>>> > On Tue, 12 May 2015, H.J. Lu wrote:
>>>> >
>>>> >> > Actually also that one is correctly printed I think (from a hello world
>>>> >> > main, where I added a jmprel16 +0):
>>>> >> >
>>>> >> > 000000000040055c <main>:
>>>> >> >   40055c:       55                      push   %rbp
>>>> >> >   40055d:       48 89 e5                mov    %rsp,%rbp
>>>> >> >   400560:       48 83 ec 30             sub    $0x30,%rsp
>>>> >> >   400564:       c6 45 d1 00             movb   $0x0,-0x2f(%rbp)
>>>> >> >   400568:       c6 45 d0 61             movb   $0x61,-0x30(%rbp)
>>>> >> >   40056c:       48 8d 45 d0             lea    -0x30(%rbp),%rax
>>>> >> >   400570:       48 89 c2                mov    %rax,%rdx
>>>> >> >   400573:       be 44 06 40 00          mov    $0x400644,%esi
>>>> >> >   400578:       66 e9 00 00             jmpw   57c <_init-0x3ffe8c>
>>>> >> >
>>>> >> > 000000000040057c <next>:
>>>> >> >   40057c:       bf 52 06 40 00          mov    $0x400652,%edi
>>>> >> >   ...
>>>> >> >
>>>> >> > It shows that rip is going to be truncated.
>>>> >> >
>>>> >>
>>>> >> This is the same issue as
>>>> >>
>>>> >> https://sourceware.org/bugzilla/show_bug.cgi?id=18386
>>>> >>
>>>> >> On Intel processors, 0x66 prefix before direct 32-bit unconditional
>>>> >> call/jmp is ignored.  Whatever we do is wrong on AMD or Intel
>>>> >> processors.
>>>> >
>>>> > Well, in that case I'd say the correct thing to do is to _not_ do any
>>>>
>>>> This is NO correct thing to do.
>>>
>>> Well, what do you suggest?  Your change is clearly wrong as well.
>>
>> I won't call it wrong since it implies there is a right.  Given that
>>
>> 0x66 jmp/call rel32
>>
>> works on Intel processors and crashes on AMD processors.
>
> What _works_ on Intel processors is secondary here. Fact is that
> the x86-64 design came from AMD, and hence Intel CPUs doing
> things differently than AMD's is - be honest - a flaw. The more

I don't think who came first is relevant here.  What relevant are

1. AMD and Intel specs are different.
2. There is no real usage for AMD spec.
3. There is a bug report against Intel spec.

> that by analogy with 32-bit mode, an operand size prefix on
> branches ought to truncate rIP. Plus (other than my own testing
> says) you seem to suggest that this isn't even consistent on Intel
> CPUs, as you specifically say "unconditional" above and you also
> only changed those.

Please open a bug report against Jcc and I will look into it.

>> I will keep my change in unlessl someone can show a real usage of
>>
>> 066 jmp/call rel16
>>
>> on AMD processors.
>
> That's the wrong position, you have to show that the change is
> useful - I certainly can't see why you'd need the operand size

https://sourceware.org/bugzilla/show_bug.cgi?id=18386

> prefix when (on Intel CPUs) it has no effect whatsoever.
> Together with it not being generally usable (due to the vendor
> differences), I view the change as pointless _and_ breaking
> compatibility (i.e. both by themselves a reason to revert).
>


-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Jan Beulich]

>>> On 13.05.15 at 13:35, <hjl.tools@gmail.com> wrote:
> On Tue, May 12, 2015 at 11:18 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> What _works_ on Intel processors is secondary here. Fact is that
>> the x86-64 design came from AMD, and hence Intel CPUs doing
>> things differently than AMD's is - be honest - a flaw. The more
> 
> I don't think who came first is relevant here.  What relevant are
> 
> 1. AMD and Intel specs are different.

Very interesting statement. If you want to stick to what Intel
specifies, then look at the "N.S." of the respective CALL/JMP
encodings. The explanation of N.S. specifically says "Using an
address override prefix in 64-bit mode may result in model-
specific execution behavior." I don't think you want the
assembler to behave in model-specific ways.

And again - Intel's treatment is inconsistent (operand size prefix
meaning different things depending on context), while AMD's is
consistent.

> 2. There is no real usage for AMD spec.

Then you could as well rip out the use of data16 on branches in
32-bit mode. And I'm sure there are a lot more cases of "no real
usage" but still being accepted/supported by the assembler.

> 3. There is a bug report against Intel spec.
> 
>> that by analogy with 32-bit mode, an operand size prefix on
>> branches ought to truncate rIP. Plus (other than my own testing
>> says) you seem to suggest that this isn't even consistent on Intel
>> CPUs, as you specifically say "unconditional" above and you also
>> only changed those.
> 
> Please open a bug report against Jcc and I will look into it.

Why would I? I don't want you to cripple Jcc too, but to restore
previous behavior for JMP and CALL.

>>> I will keep my change in unlessl someone can show a real usage of
>>>
>>> 066 jmp/call rel16
>>>
>>> on AMD processors.
>>
>> That's the wrong position, you have to show that the change is
>> useful - I certainly can't see why you'd need the operand size
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=18386 

But that bug report is simply invalid when considering AMD CPUs.
Hence it should be rejected as such.

Jan

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Michael Matz]

Hi,

On Tue, 12 May 2015, H.J. Lu wrote:

> > Well, what do you suggest?  Your change is clearly wrong as well.
> 
> I won't call it wrong since it implies there is a right.

Of course there is a right.  The x86-64 specification is quite clear what 
happens with the prefix on jumps.  Intel CPUs are simply buggy in not 
implementing it.  And you're making binutils follow that buggy behaviour.  
And that is wrong.  The associated bug report is invalid.

> Given that
> 
> 0x66 jmp/call rel32
> 
> works on Intel processors and crashes on AMD processors.
> I will keep my change in unlessl someone can show a real usage of
> 
> 066 jmp/call rel16
> 
> on AMD processors.

Huh, what?  I must say I'm not very fond of your way of maintaining the 
x86-64 binutils.


Ciao,
Michael.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Wed, May 13, 2015 at 5:27 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 13.05.15 at 13:35, <hjl.tools@gmail.com> wrote:
>> On Tue, May 12, 2015 at 11:18 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>> What _works_ on Intel processors is secondary here. Fact is that
>>> the x86-64 design came from AMD, and hence Intel CPUs doing
>>> things differently than AMD's is - be honest - a flaw. The more
>>
>> I don't think who came first is relevant here.  What relevant are
>>
>> 1. AMD and Intel specs are different.
>
> Very interesting statement. If you want to stick to what Intel
> specifies, then look at the "N.S." of the respective CALL/JMP
> encodings. The explanation of N.S. specifically says "Using an
> address override prefix in 64-bit mode may result in model-
> specific execution behavior." I don't think you want the
> assembler to behave in model-specific ways.

Intel SDM says

A relative offset (rel16 or rel32) is generally specified as a label
in assembly code. But at the machine code level, it
is encoded as a signed, 16- or 32-bit immediate value. This value is
added to the value in the EIP(RIP) register. In
64-bit mode the relative offset is always a 32-bit immediate value
which is sign extended to 64-bits before it is
added to the value in the RIP register for the target calculation. As
with absolute offsets, the operand-size attribute
determines the size of the target operand (16, 32, or 64 bits). In
64-bit mode the target operand will always be 64-
bits because the operand size is forced to 64-bits for near branches.A
relative offset (rel16 or rel32) is generally specified as a label in
assembly code. But at the machine code level, it
is encoded as a signed, 16- or 32-bit immediate value. This value is
added to the value in the EIP(RIP) register. In
64-bit mode the relative offset is always a 32-bit immediate value
which is sign extended to 64-bits before it is
added to the value in the RIP register for the target calculation. As
with absolute offsets, the operand-size attribute
determines the size of the target operand (16, 32, or 64 bits). In
64-bit mode the target operand will always be 64-
bits because the operand size is forced to 64-bits for near branches.

It is always 64-bit in 64-bit mode on Intel processors.

> And again - Intel's treatment is inconsistent (operand size prefix
> meaning different things depending on context), while AMD's is
> consistent.

This isn't a good situation and I can't find a good compromise.
I am open to all suggestions.

-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Wed, May 13, 2015 at 5:34 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 12 May 2015, H.J. Lu wrote:
>
>> > Well, what do you suggest?  Your change is clearly wrong as well.
>>
>> I won't call it wrong since it implies there is a right.
>
> Of course there is a right.  The x86-64 specification is quite clear what
> happens with the prefix on jumps.  Intel CPUs are simply buggy in not
> implementing it.  And you're making binutils follow that buggy behaviour.

AMD64 and Intel64 differ in some subtle ways.

> And that is wrong.  The associated bug report is invalid.

How about this

1.  Add flavors of AMD64 and Intel64 to assembler.  Make the most
permissive one as the default.  In case of call/jmp, the default will
take AMD64.
2.  Add -Mintel64/-Mamd64 to objdump,  Make the most permissive
ones the default.

>> Given that
>>
>> 0x66 jmp/call rel32
>>
>> works on Intel processors and crashes on AMD processors.
>> I will keep my change in unlessl someone can show a real usage of
>>
>> 066 jmp/call rel16
>>
>> on AMD processors.
>
> Huh, what?  I must say I'm not very fond of your way of maintaining the
> x86-64 binutils.
>

I am keen to improve.  Pleas feel free to point outs things I should work on.

Thanks.


-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Maciej W. Rozycki]

On Wed, 13 May 2015, H.J. Lu wrote:

> >> > Well, what do you suggest?  Your change is clearly wrong as well.
> >>
> >> I won't call it wrong since it implies there is a right.
> >
> > Of course there is a right.  The x86-64 specification is quite clear what
> > happens with the prefix on jumps.  Intel CPUs are simply buggy in not
> > implementing it.  And you're making binutils follow that buggy behaviour.
> 
> AMD64 and Intel64 differ in some subtle ways.
> 
> > And that is wrong.  The associated bug report is invalid.
> 
> How about this
> 
> 1.  Add flavors of AMD64 and Intel64 to assembler.  Make the most
> permissive one as the default.  In case of call/jmp, the default will
> take AMD64.
> 2.  Add -Mintel64/-Mamd64 to objdump,  Make the most permissive
> ones the default.

 FWIW I think this will be the right direction, though the exact options 
may have to be discussed yet.

 The assembler is a tool, it should not be forcing a use policy upon 
users.  Therefore it should allow whatever is encodable given the 
instruction set definition and let users decide themselves how to use 
it, whether implementations follow the rules or not.

 And then if you want to add safety traps such as for this difference 
between individual model implementations, then wire them to `-march=' or 
suchlike.

  Maciej

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Wed, May 13, 2015 at 9:50 AM, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Wed, 13 May 2015, H.J. Lu wrote:
>
>> >> > Well, what do you suggest?  Your change is clearly wrong as well.
>> >>
>> >> I won't call it wrong since it implies there is a right.
>> >
>> > Of course there is a right.  The x86-64 specification is quite clear what
>> > happens with the prefix on jumps.  Intel CPUs are simply buggy in not
>> > implementing it.  And you're making binutils follow that buggy behaviour.
>>
>> AMD64 and Intel64 differ in some subtle ways.
>>
>> > And that is wrong.  The associated bug report is invalid.
>>
>> How about this
>>
>> 1.  Add flavors of AMD64 and Intel64 to assembler.  Make the most
>> permissive one as the default.  In case of call/jmp, the default will
>> take AMD64.
>> 2.  Add -Mintel64/-Mamd64 to objdump,  Make the most permissive
>> ones the default.
>
>  FWIW I think this will be the right direction, though the exact options
> may have to be discussed yet.
>
>  The assembler is a tool, it should not be forcing a use policy upon
> users.  Therefore it should allow whatever is encodable given the
> instruction set definition and let users decide themselves how to use
> it, whether implementations follow the rules or not.
>
>  And then if you want to add safety traps such as for this difference
> between individual model implementations, then wire them to `-march=' or
> suchlike.

Thanks for your feedbacks.  I am waiting for feedbacks from Jan and
Michael before I start investigation.


-- 
H.J.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Jan Beulich]

>>> On 13.05.15 at 18:53, <hjl.tools@gmail.com> wrote:
> On Wed, May 13, 2015 at 9:50 AM, Maciej W. Rozycki <macro@linux-mips.org> 
> wrote:
>> On Wed, 13 May 2015, H.J. Lu wrote:
>>
>>> >> > Well, what do you suggest?  Your change is clearly wrong as well.
>>> >>
>>> >> I won't call it wrong since it implies there is a right.
>>> >
>>> > Of course there is a right.  The x86-64 specification is quite clear what
>>> > happens with the prefix on jumps.  Intel CPUs are simply buggy in not
>>> > implementing it.  And you're making binutils follow that buggy behaviour.
>>>
>>> AMD64 and Intel64 differ in some subtle ways.
>>>
>>> > And that is wrong.  The associated bug report is invalid.
>>>
>>> How about this
>>>
>>> 1.  Add flavors of AMD64 and Intel64 to assembler.  Make the most
>>> permissive one as the default.  In case of call/jmp, the default will
>>> take AMD64.
>>> 2.  Add -Mintel64/-Mamd64 to objdump,  Make the most permissive
>>> ones the default.
>>
>>  FWIW I think this will be the right direction, though the exact options
>> may have to be discussed yet.
>>
>>  The assembler is a tool, it should not be forcing a use policy upon
>> users.  Therefore it should allow whatever is encodable given the
>> instruction set definition and let users decide themselves how to use
>> it, whether implementations follow the rules or not.
>>
>>  And then if you want to add safety traps such as for this difference
>> between individual model implementations, then wire them to `-march=' or
>> suchlike.
> 
> Thanks for your feedbacks.  I am waiting for feedbacks from Jan and
> Michael before I start investigation.

Not sure what else feedback you expect - after all I had suggested
the introduction of command line options or alike to control the
specific behavior. All I'm really after is that without any such override
given behavior remain like what it is in 2.25.

Jan

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

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

On Thu, May 14, 2015 at 11:39 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 13.05.15 at 18:53, <hjl.tools@gmail.com> wrote:
>> On Wed, May 13, 2015 at 9:50 AM, Maciej W. Rozycki <macro@linux-mips.org>
>> wrote:
>>> On Wed, 13 May 2015, H.J. Lu wrote:
>>>
>>>> >> > Well, what do you suggest?  Your change is clearly wrong as well.
>>>> >>
>>>> >> I won't call it wrong since it implies there is a right.
>>>> >
>>>> > Of course there is a right.  The x86-64 specification is quite clear what
>>>> > happens with the prefix on jumps.  Intel CPUs are simply buggy in not
>>>> > implementing it.  And you're making binutils follow that buggy behaviour.
>>>>
>>>> AMD64 and Intel64 differ in some subtle ways.
>>>>
>>>> > And that is wrong.  The associated bug report is invalid.
>>>>
>>>> How about this
>>>>
>>>> 1.  Add flavors of AMD64 and Intel64 to assembler.  Make the most
>>>> permissive one as the default.  In case of call/jmp, the default will
>>>> take AMD64.
>>>> 2.  Add -Mintel64/-Mamd64 to objdump,  Make the most permissive
>>>> ones the default.
>>>
>>>  FWIW I think this will be the right direction, though the exact options
>>> may have to be discussed yet.
>>>
>>>  The assembler is a tool, it should not be forcing a use policy upon
>>> users.  Therefore it should allow whatever is encodable given the
>>> instruction set definition and let users decide themselves how to use
>>> it, whether implementations follow the rules or not.
>>>
>>>  And then if you want to add safety traps such as for this difference
>>> between individual model implementations, then wire them to `-march=' or
>>> suchlike.
>>
>> Thanks for your feedbacks.  I am waiting for feedbacks from Jan and
>> Michael before I start investigation.
>
> Not sure what else feedback you expect - after all I had suggested
> the introduction of command line options or alike to control the
> specific behavior. All I'm really after is that without any such override
> given behavior remain like what it is in 2.25.
>

That is what I checked in.

-- 
H.J.
---
AMD64 spec and Intel64 spec differ in direct unconditional branches in
64-bit mode.  AMD64 supports direct unconditional branches with 16-bit
offset via the data size prefix, which truncates RIP to 16 bits, while
the data size prefix is ignored by Intel64.

This patch adds -mamd64/-mintel64 option to x86-64 assembler and
-Mamd64/-Mintel64 option to x86-64 disassembler.  The most permissive
ISA, which is AMD64, is the default.

GDB can add an option, similar to

(gdb) help set disassembly-flavor
Set the disassembly flavor.
The valid values are "att" and "intel", and the default value is "att".

to select which ISA to disassemble.

binutils/

PR binutis/18386
gnu-6:pts/14[321]> m
0001-Support-AMD64-Intel-ISAs-in-assembler-disassembler.patch
Date: Fri, 15 May 2015 09:47:39 -0700
Subject: [PATCH] Support AMD64/Intel ISAs in assembler/disassembler

AMD64 spec and Intel64 spec differ in direct unconditional branches in
64-bit mode.  AMD64 supports direct unconditional branches with 16-bit
offset via the data size prefix, which truncates RIP to 16 bits, while
the data size prefix is ignored by Intel64.

This patch adds -mamd64/-mintel64 option to x86-64 assembler and
-Mamd64/-Mintel64 option to x86-64 disassembler.  The most permissive
ISA, which is AMD64, is the default.

GDB can add an option, similar to

(gdb) help set disassembly-flavor
Set the disassembly flavor.
The valid values are "att" and "intel", and the default value is "att".

to select which ISA to disassemble.

binutils/

PR binutis/18386
* doc/binutils.texi: Document -Mamd64 and -Mintel64.

gas/

PR binutis/18386
* config/tc-i386.c (OPTION_MAMD64): New.
(OPTION_MINTEL64): Likewise.
(md_longopts): Add -mamd64 and -mintel64.
(md_parse_option): Handle OPTION_MAMD64 and OPTION_MINTEL64.
(md_show_usage): Add -mamd64 and -mintel64.
* doc/c-i386.texi: Document -mamd64 and -mintel64.

gas/testsuite/

PR binutis/18386
* gas/i386/i386.exp: Run x86-64-branch-2 and x86-64-branch-3.
* gas/i386/x86-64-branch.d: Also pass -Mintel64 to objdump.
* gas/i386/ilp32/x86-64-branch.d: Likewise.
* gas/i386/x86-64-branch-2.d: New file.
* gas/i386/x86-64-branch-2.s: Likewise.
* gas/i386/x86-64-branch-3.l: Likewise.
* gas/i386/x86-64-branch-3.s: Likewise.

ld/testsuite/

PR binutis/18386
* ld-x86-64/tlsgdesc.dd: Also pass -Mintel64 to objdump.
* ld-x86-64/tlspic.dd: Likewise.
* ld-x86-64/x86-64.exp (x86_64tests): Also pass -Mintel64 to
objdump for tlspic.dd and tlsgdesc.dd.

opcodes/

PR binutis/18386
* i386-dis.c: Add comments for '@'.
(x86_64_table): Use '@' on call/jmp for X86_64_E8/X86_64_E9.
(enum x86_64_isa): New.
(isa64): Likewise.
(print_i386_disassembler_options): Add amd64 and intel64.
(print_insn): Handle amd64 and intel64.
(putop): Handle '@'.
(OP_J): Don't ignore the operand size prefix for AMD64 in 64-bit.
* i386-gen.c (cpu_flags): Add CpuAMD64 and CpuIntel64.
* i386-opc.h (AMD64): New.
(CpuIntel64): Likewise.
(i386_cpu_flags): Add cpuamd64 and cpuintel64.
* i386-opc.tbl: Add direct call/jmp with Disp16|Disp32 for AMD64.
Mark direct call/jmp without Disp16|Disp32 as Intel64.
* i386-init.h: Regenerated.
* i386-tbl.h: Likewise.

[-- Attachment #2: 0001-Support-AMD64-Intel-ISAs-in-assembler-disassembler.patch --]
[-- Type: text/x-patch, Size: 22017 bytes --]

Date: Fri, 15 May 2015 09:47:39 -0700
Subject: [PATCH] Support AMD64/Intel ISAs in assembler/disassembler

AMD64 spec and Intel64 spec differ in direct unconditional branches in
64-bit mode.  AMD64 supports direct unconditional branches with 16-bit
offset via the data size prefix, which truncates RIP to 16 bits, while
the data size prefix is ignored by Intel64.

This patch adds -mamd64/-mintel64 option to x86-64 assembler and
-Mamd64/-Mintel64 option to x86-64 disassembler.  The most permissive
ISA, which is AMD64, is the default.

GDB can add an option, similar to

(gdb) help set disassembly-flavor
Set the disassembly flavor.
The valid values are "att" and "intel", and the default value is "att".

to select which ISA to disassemble.

binutils/

	PR binutis/18386
	* doc/binutils.texi: Document -Mamd64 and -Mintel64.

gas/

	PR binutis/18386
	* config/tc-i386.c (OPTION_MAMD64): New.
	(OPTION_MINTEL64): Likewise.
	(md_longopts): Add -mamd64 and -mintel64.
	(md_parse_option): Handle OPTION_MAMD64 and OPTION_MINTEL64.
	(md_show_usage): Add -mamd64 and -mintel64.
	* doc/c-i386.texi: Document -mamd64 and -mintel64.

gas/testsuite/

	PR binutis/18386
	* gas/i386/i386.exp: Run x86-64-branch-2 and x86-64-branch-3.
	* gas/i386/x86-64-branch.d: Also pass -Mintel64 to objdump.
	* gas/i386/ilp32/x86-64-branch.d: Likewise.
	* gas/i386/x86-64-branch-2.d: New file.
	* gas/i386/x86-64-branch-2.s: Likewise.
	* gas/i386/x86-64-branch-3.l: Likewise.
	* gas/i386/x86-64-branch-3.s: Likewise.

ld/testsuite/

	PR binutis/18386
	* ld-x86-64/tlsgdesc.dd: Also pass -Mintel64 to objdump.
	* ld-x86-64/tlspic.dd: Likewise.
	* ld-x86-64/x86-64.exp (x86_64tests): Also pass -Mintel64 to
	objdump for tlspic.dd and tlsgdesc.dd.

opcodes/

	PR binutis/18386
	* i386-dis.c: Add comments for '@'.
	(x86_64_table): Use '@' on call/jmp for X86_64_E8/X86_64_E9.
	(enum x86_64_isa): New.
	(isa64): Likewise.
	(print_i386_disassembler_options): Add amd64 and intel64.
	(print_insn): Handle amd64 and intel64.
	(putop): Handle '@'.
	(OP_J): Don't ignore the operand size prefix for AMD64 in 64-bit.
	* i386-gen.c (cpu_flags): Add CpuAMD64 and CpuIntel64.
	* i386-opc.h (AMD64): New.
	(CpuIntel64): Likewise.
	(i386_cpu_flags): Add cpuamd64 and cpuintel64.
	* i386-opc.tbl: Add direct call/jmp with Disp16|Disp32 for AMD64.
	Mark direct call/jmp without Disp16|Disp32 as Intel64.
	* i386-init.h: Regenerated.
	* i386-tbl.h: Likewise.
---
 binutils/ChangeLog                           |     5 +
 binutils/doc/binutils.texi                   |     4 +
 gas/ChangeLog                                |    10 +
 gas/config/tc-i386.c                         |    22 +
 gas/doc/c-i386.texi                          |     7 +
 gas/testsuite/ChangeLog                      |    11 +
 gas/testsuite/gas/i386/i386.exp              |     2 +
 gas/testsuite/gas/i386/ilp32/x86-64-branch.d |     2 +-
 gas/testsuite/gas/i386/x86-64-branch-2.d     |    15 +
 gas/testsuite/gas/i386/x86-64-branch-2.s     |     7 +
 gas/testsuite/gas/i386/x86-64-branch-3.l     |    17 +
 gas/testsuite/gas/i386/x86-64-branch-3.s     |     7 +
 gas/testsuite/gas/i386/x86-64-branch.d       |     2 +-
 ld/testsuite/ChangeLog                       |     8 +
 ld/testsuite/ld-x86-64/tlsgdesc.dd           |     2 +-
 ld/testsuite/ld-x86-64/tlspic.dd             |     2 +-
 ld/testsuite/ld-x86-64/x86-64.exp            |     4 +-
 opcodes/ChangeLog                            |    20 +
 opcodes/i386-dis.c                           |    45 +-
 opcodes/i386-gen.c                           |     2 +
 opcodes/i386-init.h                          |   212 +-
 opcodes/i386-opc.h                           |     6 +
 opcodes/i386-opc.tbl                         |     6 +-
 opcodes/i386-tbl.h                           | 10392 +++++++++++++------------
 24 files changed, 5508 insertions(+), 5302 deletions(-)
 create mode 100644 gas/testsuite/gas/i386/x86-64-branch-2.d
 create mode 100644 gas/testsuite/gas/i386/x86-64-branch-2.s
 create mode 100644 gas/testsuite/gas/i386/x86-64-branch-3.l
 create mode 100644 gas/testsuite/gas/i386/x86-64-branch-3.s

diff --git a/binutils/ChangeLog b/binutils/ChangeLog
index ee2ddf0..2328f6e 100644
--- a/binutils/ChangeLog
+++ b/binutils/ChangeLog
@@ -1,3 +1,8 @@
+2015-05-15  H.J. Lu  <hongjiu.lu@intel.com>
+
+	PR binutis/18386
+	* doc/binutils.texi: Document -Mamd64 and -Mintel64.
+
 2015-05-15  Nick Clifton  <nickc@redhat.com>
 
 	* readelf.c (options): Add "decompress".
diff --git a/binutils/doc/binutils.texi b/binutils/doc/binutils.texi
index 619c28e..75852e6 100644
--- a/binutils/doc/binutils.texi
+++ b/binutils/doc/binutils.texi
@@ -2175,6 +2175,10 @@ Select disassembly for the given architecture.
 @itemx att
 Select between intel syntax mode and AT&T syntax mode.
 
+@item amd64
+@itemx intel64
+Select between AMD64 ISA and Intel64 ISA.
+
 @item intel-mnemonic
 @itemx att-mnemonic
 Select between intel mnemonic mode and AT&T mnemonic mode.
diff --git a/gas/ChangeLog b/gas/ChangeLog
index 9bc4a15..6cd3639 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,5 +1,15 @@
 2015-05-15  H.J. Lu  <hongjiu.lu@intel.com>
 
+	PR binutis/18386
+	* config/tc-i386.c (OPTION_MAMD64): New.
+	(OPTION_MINTEL64): Likewise.
+	(md_longopts): Add -mamd64 and -mintel64.
+	(md_parse_option): Handle OPTION_MAMD64 and OPTION_MINTEL64.
+	(md_show_usage): Add -mamd64 and -mintel64.
+	* doc/c-i386.texi: Document -mamd64 and -mintel64.
+
+2015-05-15  H.J. Lu  <hongjiu.lu@intel.com>
+
 	* config/tc-i386.c (shared): New.
 	(OPTION_MSHARED): Likewise.
 	(elf_symbol_resolved_in_segment_p): Add relocation argument.
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index 254548f..34b5c28 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -9550,6 +9550,8 @@ const char *md_shortopts = "qn";
 #define OPTION_OMIT_LOCK_PREFIX (OPTION_MD_BASE + 19)
 #define OPTION_MEVEXRCIG (OPTION_MD_BASE + 20)
 #define OPTION_MSHARED (OPTION_MD_BASE + 21)
+#define OPTION_MAMD64 (OPTION_MD_BASE + 22)
+#define OPTION_MINTEL64 (OPTION_MD_BASE + 23)
 
 struct option md_longopts[] =
 {
@@ -9582,6 +9584,8 @@ struct option md_longopts[] =
 #endif
   {"momit-lock-prefix", required_argument, NULL, OPTION_OMIT_LOCK_PREFIX},
   {"mevexrcig", required_argument, NULL, OPTION_MEVEXRCIG},
+  {"mamd64", no_argument, NULL, OPTION_MAMD64},
+  {"mintel64", no_argument, NULL, OPTION_MINTEL64},
   {NULL, no_argument, NULL, 0}
 };
 size_t md_longopts_size = sizeof (md_longopts);
@@ -9898,6 +9902,20 @@ md_parse_option (int c, char *arg)
         as_fatal (_("invalid -momit-lock-prefix= option: `%s'"), arg);
       break;
 
+    case OPTION_MAMD64:
+      cpu_arch_flags.bitfield.cpuamd64 = 1;
+      cpu_arch_flags.bitfield.cpuintel64 = 0;
+      cpu_arch_isa_flags.bitfield.cpuamd64 = 1;
+      cpu_arch_isa_flags.bitfield.cpuintel64 = 0;
+      break;
+
+    case OPTION_MINTEL64:
+      cpu_arch_flags.bitfield.cpuamd64 = 0;
+      cpu_arch_flags.bitfield.cpuintel64 = 1;
+      cpu_arch_isa_flags.bitfield.cpuamd64 = 0;
+      cpu_arch_isa_flags.bitfield.cpuintel64 = 1;
+      break;
+
     default:
       return 0;
     }
@@ -10063,6 +10081,10 @@ md_show_usage (FILE *stream)
   fprintf (stream, _("\
   -momit-lock-prefix=[no|yes]\n\
                           strip all lock prefixes\n"));
+  fprintf (stream, _("\
+  -mamd64                 accept only AMD64 ISA\n"));
+  fprintf (stream, _("\
+  -mintel64               accept only Intel64 ISA\n"));
 }
 
 #if ((defined (OBJ_MAYBE_COFF) && defined (OBJ_MAYBE_AOUT)) \
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index ea08c63..6118987 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -339,6 +339,13 @@ of EVEX instruction with 00, which is the default.
 and @option{-mevexrcig=@var{rz}} will encode SAE-only EVEX instructions
 with 01, 10 and 11 RC bits, respectively.
 
+@cindex @samp{-mamd64} option, x86-64
+@cindex @samp{-mintel64} option, x86-64
+@item -mamd64
+@itemx -mintel64
+This option specifies that the assembler should accept only AMD64 or
+Intel64 ISA in 64-bit mode.  The default is to accept both.
+
 @end table
 @c man end
 
diff --git a/gas/testsuite/ChangeLog b/gas/testsuite/ChangeLog
index 95b7583..7f4b81b 100644
--- a/gas/testsuite/ChangeLog
+++ b/gas/testsuite/ChangeLog
@@ -1,5 +1,16 @@
 2015-05-15  H.J. Lu  <hongjiu.lu@intel.com>
 
+	PR binutis/18386
+	* gas/i386/i386.exp: Run x86-64-branch-2 and x86-64-branch-3.
+	* gas/i386/x86-64-branch.d: Also pass -Mintel64 to objdump.
+	* gas/i386/ilp32/x86-64-branch.d: Likewise.
+	* gas/i386/x86-64-branch-2.d: New file.
+	* gas/i386/x86-64-branch-2.s: Likewise.
+	* gas/i386/x86-64-branch-3.l: Likewise.
+	* gas/i386/x86-64-branch-3.s: Likewise.
+
+2015-05-15  H.J. Lu  <hongjiu.lu@intel.com>
+
 	* gas/i386/i386.exp: Don't run pcrel for ELF targets.  Run
 	pcrel-elf, relax-4 and x86-64-relax-3 for ELF targets.
 	* gas/i386/pcrel-elf.d: New file.
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index ff648b0..9ff38d3 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -770,6 +770,8 @@ if [expr ([istarget "i*86-*-*"] || [istarget "x86_64-*-*"]) && [gas_64_check]] t
 	run_dump_test "x86-64-relax-3"
 
 	run_dump_test "x86-64-jump"
+	run_dump_test "x86-64-branch-2"
+	run_list_test "x86-64-branch-3" "-al -mintel64"
     }
 
     set ASFLAGS "$old_ASFLAGS"
diff --git a/gas/testsuite/gas/i386/ilp32/x86-64-branch.d b/gas/testsuite/gas/i386/ilp32/x86-64-branch.d
index 9fcb8ca..8200282 100644
--- a/gas/testsuite/gas/i386/ilp32/x86-64-branch.d
+++ b/gas/testsuite/gas/i386/ilp32/x86-64-branch.d
@@ -1,6 +1,6 @@
 #source: ../x86-64-branch.s
 #as: -J
-#objdump: -drw
+#objdump: -drw -Mintel64
 #name: x86-64 (ILP32) branch
 
 .*: +file format .*
diff --git a/gas/testsuite/gas/i386/x86-64-branch-2.d b/gas/testsuite/gas/i386/x86-64-branch-2.d
new file mode 100644
index 0000000..5078daa
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-branch-2.d
@@ -0,0 +1,15 @@
+#as: -J
+#objdump: -dwr
+#name: x86-64 branch 2
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+ <bar-0x4>:
+[ 	]*[a-f0-9]+:	66 e9 00 00          	jmpw   4 <bar>	2: R_X86_64_PC16	foo-0x2
+
+0+4 <bar>:
+[ 	]*[a-f0-9]+:	89 c3                	mov    %eax,%ebx
+[ 	]*[a-f0-9]+:	66 e8 00 00          	callw  a <bar\+0x6>	8: R_X86_64_PC16	foo-0x2
+#pass
diff --git a/gas/testsuite/gas/i386/x86-64-branch-2.s b/gas/testsuite/gas/i386/x86-64-branch-2.s
new file mode 100644
index 0000000..16c85a3
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-branch-2.s
@@ -0,0 +1,7 @@
+	.text
+	data16 jmp foo
+
+bar:
+	mov %eax, %ebx
+
+	data16 call foo
diff --git a/gas/testsuite/gas/i386/x86-64-branch-3.l b/gas/testsuite/gas/i386/x86-64-branch-3.l
new file mode 100644
index 0000000..de3c2dd
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-branch-3.l
@@ -0,0 +1,17 @@
+.*: Assembler messages:
+.*:2: Warning: indirect jmp without `\*'
+.*:7: Warning: indirect call without `\*'
+GAS LISTING .*
+
+
+[ 	]*1[ 	]+\.text
+[ 	]*2[ 	]+0000 66FF2C25 		data16 jmp foo
+\*\*\*\*  Warning: indirect jmp without `\*'
+[ 	]*2[ 	]+00000000 
+[ 	]*3[ 	]+
+[ 	]*4[ 	]+bar:
+[ 	]*5[ 	]+0008 89C3     		mov %eax, %ebx
+[ 	]*6[ 	]+
+[ 	]*7[ 	]+000a 66FF1C25 		data16 call foo
+\*\*\*\*  Warning: indirect call without `\*'
+[ 	]*7[ 	]+00000000 
diff --git a/gas/testsuite/gas/i386/x86-64-branch-3.s b/gas/testsuite/gas/i386/x86-64-branch-3.s
new file mode 100644
index 0000000..16c85a3
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-branch-3.s
@@ -0,0 +1,7 @@
+	.text
+	data16 jmp foo
+
+bar:
+	mov %eax, %ebx
+
+	data16 call foo
diff --git a/gas/testsuite/gas/i386/x86-64-branch.d b/gas/testsuite/gas/i386/x86-64-branch.d
index 49e17a4..612acc0 100644
--- a/gas/testsuite/gas/i386/x86-64-branch.d
+++ b/gas/testsuite/gas/i386/x86-64-branch.d
@@ -1,5 +1,5 @@
 #as: -J
-#objdump: -dw
+#objdump: -dw -Mintel64
 #name: x86-64 branch
 
 .*: +file format .*
diff --git a/ld/testsuite/ChangeLog b/ld/testsuite/ChangeLog
index a7b006c..43c7c24 100644
--- a/ld/testsuite/ChangeLog
+++ b/ld/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2015-05-15  H.J. Lu  <hongjiu.lu@intel.com>
+
+	PR binutis/18386
+	* ld-x86-64/tlsgdesc.dd: Also pass -Mintel64 to objdump.
+	* ld-x86-64/tlspic.dd: Likewise.
+	* ld-x86-64/x86-64.exp (x86_64tests): Also pass -Mintel64 to
+	objdump for tlspic.dd and tlsgdesc.dd.
+
 2015-05-12  H.J. Lu  <hongjiu.lu@intel.com>
 
 	* ld-i386/i386.exp: Run pltgot-1 for Linux targets.
diff --git a/ld/testsuite/ld-x86-64/tlsgdesc.dd b/ld/testsuite/ld-x86-64/tlsgdesc.dd
index 88eb953..a983a75 100644
--- a/ld/testsuite/ld-x86-64/tlsgdesc.dd
+++ b/ld/testsuite/ld-x86-64/tlsgdesc.dd
@@ -1,7 +1,7 @@
 #source: tlsgdesc.s
 #as: --64
 #ld: -shared -melf_x86_64 --no-ld-generated-unwind-info
-#objdump: -drj.text
+#objdump: -drj.text -Mintel64
 #target: x86_64-*-*
 
 .*: +file format elf64-x86-64.*
diff --git a/ld/testsuite/ld-x86-64/tlspic.dd b/ld/testsuite/ld-x86-64/tlspic.dd
index aab8181..bf3ba69 100644
--- a/ld/testsuite/ld-x86-64/tlspic.dd
+++ b/ld/testsuite/ld-x86-64/tlspic.dd
@@ -2,7 +2,7 @@
 #source: tlspic2.s
 #as: --64
 #ld: -shared -melf_x86_64 --no-ld-generated-unwind-info
-#objdump: -drj.text
+#objdump: -drj.text -Mintel64
 #target: x86_64-*-*
 
 .*: +file format elf64-x86-64.*
diff --git a/ld/testsuite/ld-x86-64/x86-64.exp b/ld/testsuite/ld-x86-64/x86-64.exp
index 58e598e..a312271 100644
--- a/ld/testsuite/ld-x86-64/x86-64.exp
+++ b/ld/testsuite/ld-x86-64/x86-64.exp
@@ -52,7 +52,7 @@ set x86_64tests {
     {"TLS -fpic -shared transitions"
      "-shared -melf_x86_64 --no-ld-generated-unwind-info" ""
      "--64" {tlspic1.s tlspic2.s}
-     {{readelf -WSsrl tlspic.rd} {objdump -drj.text tlspic.dd}
+     {{readelf -WSsrl tlspic.rd} {objdump -drj.text\ -Mintel64 tlspic.dd}
       {objdump -sj.got tlspic.sd} {objdump -sj.tdata tlspic.td}}
       "libtlspic.so"}
     {"TLS descriptor -fpic -shared transitions"
@@ -78,7 +78,7 @@ set x86_64tests {
     {"TLS with global dynamic and descriptors"
      "-shared -melf_x86_64 --no-ld-generated-unwind-info" ""
      "--64" {tlsgdesc.s}
-     {{readelf -WSsrl tlsgdesc.rd} {objdump -drj.text tlsgdesc.dd}}
+     {{readelf -WSsrl tlsgdesc.rd} {objdump -drj.text\ -Mintel64 tlsgdesc.dd}}
       "libtlsgdesc.so"}
     {"TLS in debug sections" "-melf_x86_64" ""
      "--64" {tlsg.s}
diff --git a/opcodes/ChangeLog b/opcodes/ChangeLog
index dbce2d3..d3f914c 100644
--- a/opcodes/ChangeLog
+++ b/opcodes/ChangeLog
@@ -1,3 +1,23 @@
+2015-05-15  H.J. Lu  <hongjiu.lu@intel.com>
+
+	PR binutis/18386
+	* i386-dis.c: Add comments for '@'.
+	(x86_64_table): Use '@' on call/jmp for X86_64_E8/X86_64_E9.
+	(enum x86_64_isa): New.
+	(isa64): Likewise.
+	(print_i386_disassembler_options): Add amd64 and intel64.
+	(print_insn): Handle amd64 and intel64.
+	(putop): Handle '@'.
+	(OP_J): Don't ignore the operand size prefix for AMD64 in 64-bit.
+	* i386-gen.c (cpu_flags): Add CpuAMD64 and CpuIntel64.
+	* i386-opc.h (AMD64): New.
+	(CpuIntel64): Likewise.
+	(i386_cpu_flags): Add cpuamd64 and cpuintel64.
+	* i386-opc.tbl: Add direct call/jmp with Disp16|Disp32 for AMD64.
+	Mark direct call/jmp without Disp16|Disp32 as Intel64.
+	* i386-init.h: Regenerated.
+	* i386-tbl.h: Likewise.
+
 2015-05-14  Peter Bergner  <bergner@vnet.ibm.com>
 
 	* ppc-opc.c (IH) New define.
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 941f699..76f3ead 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -2418,6 +2418,8 @@ struct dis386 {
    '%' => add 1 upper case letter to the macro.
    '^' => print 'w' or 'l' depending on operand size prefix or
 	  suffix_always is true (lcall/ljmp).
+   '@' => print 'q' for Intel64 ISA, 'w' or 'q' for AMD64 ISA depending
+	  on operand size prefix.
 
    2 upper case letter macros:
    "XY" => print 'x' or 'y' if suffix_always is true or no register
@@ -6844,13 +6846,13 @@ static const struct dis386 x86_64_table[][2] = {
   /* X86_64_E8 */
   {
     { "callP",		{ Jv, BND }, 0 },
-    { "callq",		{ Jv, BND }, 0 }
+    { "call@",		{ Jv, BND }, 0 }
   },
 
   /* X86_64_E9 */
   {
     { "jmpP",		{ Jv, BND }, 0 },
-    { "jmpq",		{ Jv, BND }, 0 }
+    { "jmp@",		{ Jv, BND }, 0 }
   },
 
   /* X86_64_EA */
@@ -12342,6 +12344,14 @@ static char close_char;
 static char separator_char;
 static char scale_char;
 
+enum x86_64_isa
+{
+  amd64 = 0,
+  intel64
+};
+
+static enum x86_64_isa isa64;
+
 /* Here for backwards compatibility.  When gdb stops using
    print_insn_i386_att and print_insn_i386_intel these functions can
    disappear, and print_insn_i386 be merged into print_insn.  */
@@ -12391,6 +12401,8 @@ with the -M switch (multiple options should be separated by commas):\n"));
   fprintf (stream, _("  data32      Assume 32bit data size\n"));
   fprintf (stream, _("  data16      Assume 16bit data size\n"));
   fprintf (stream, _("  suffix      Always display instruction suffix in AT&T syntax\n"));
+  fprintf (stream, _("  amd64       Display instruction in AMD64 ISA\n"));
+  fprintf (stream, _("  intel64     Display instruction in Intel64 ISA\n"));
 }
 
 /* Bad opcode.  */
@@ -12874,7 +12886,11 @@ print_insn (bfd_vma pc, disassemble_info *info)
 
   for (p = info->disassembler_options; p != NULL; )
     {
-      if (CONST_STRNEQ (p, "x86-64"))
+      if (CONST_STRNEQ (p, "amd64"))
+	isa64 = amd64;
+      else if (CONST_STRNEQ (p, "intel64"))
+	isa64 = intel64;
+      else if (CONST_STRNEQ (p, "x86-64"))
 	{
 	  address_mode = mode_64bit;
 	  priv.orig_sizeflag = AFLAG | DFLAG;
@@ -14208,6 +14224,20 @@ case_S:
 	      used_prefixes |= (prefixes & PREFIX_DATA);
 	    }
 	  break;
+	case '@':
+	  if (intel_syntax)
+	    break;
+	  if (address_mode == mode_64bit
+	      && (isa64 == intel64
+		  || ((sizeflag & DFLAG) || (rex & REX_W))))
+	      *obufp++ = 'q';
+	  else if ((prefixes & PREFIX_DATA))
+	    {
+	      if (!(sizeflag & DFLAG))
+		*obufp++ = 'w';
+	      used_prefixes |= (prefixes & PREFIX_DATA);
+	    }
+	  break;
 	}
       alt = 0;
     }
@@ -15724,7 +15754,11 @@ OP_J (int bytemode, int sizeflag)
 	disp -= 0x100;
       break;
     case v_mode:
-      if (address_mode == mode_64bit || (sizeflag & DFLAG))
+      if (isa64 == amd64)
+	USED_REX (REX_W);
+      if ((sizeflag & DFLAG)
+	  || (address_mode == mode_64bit
+	      && (isa64 != amd64 || (rex & REX_W))))
 	disp = get32s ();
       else
 	{
@@ -15740,7 +15774,8 @@ OP_J (int bytemode, int sizeflag)
 	    segment = ((start_pc + codep - start_codep)
 		       & ~((bfd_vma) 0xffff));
 	}
-      if (address_mode != mode_64bit)
+      if (address_mode != mode_64bit
+	  || (isa64 == amd64 && !(rex & REX_W)))
 	used_prefixes |= (prefixes & PREFIX_DATA);
       break;
     default:
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index 216bc49..0523936 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -458,6 +458,8 @@ static bitfield cpu_flags[] =
   BITFIELD (CpuAVX512IFMA),
   BITFIELD (CpuAVX512VBMI),
   BITFIELD (CpuCLZERO),
+  BITFIELD (CpuAMD64),
+  BITFIELD (CpuIntel64),
 #ifdef CpuUnused
   BITFIELD (CpuUnused),
 #endif
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index ff9b32c..62ac42a 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -200,6 +200,10 @@ enum
   Cpu64,
   /* Not supported in the 64bit mode  */
   CpuNo64,
+  /* AMD64 support required  */
+  CpuAMD64,
+  /* Intel64 support required  */
+  CpuIntel64,
   /* The last bitfield in i386_cpu_flags.  */
   CpuMax = CpuNo64
 };
@@ -303,6 +307,8 @@ typedef union i386_cpu_flags
       unsigned int cpuclzero:1;
       unsigned int cpu64:1;
       unsigned int cpuno64:1;
+      unsigned int cpuamd64:1;
+      unsigned int cpuintel64:1;
 #ifdef CpuUnused
       unsigned int unused:(CpuNumOfBits - CpuUnused);
 #endif
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index ca629c4..56eddbf 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -319,7 +319,8 @@ shrd, 2, 0xfad, None, 2, Cpu386, Modrm|CheckRegSize|No_bSuf|No_sSuf|No_ldSuf, {
 
 // Control transfer instructions.
 call, 1, 0xe8, None, 1, CpuNo64, JumpDword|DefaultSize|No_bSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Disp16|Disp32 }
-call, 1, 0xe8, None, 1, Cpu64, JumpDword|DefaultSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk, { Disp32S }
+call, 1, 0xe8, None, 1, Cpu64|CpuAMD64, JumpDword|DefaultSize|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk, { Disp16|Disp32|Disp32S }
+call, 1, 0xe8, None, 1, Cpu64|CpuIntel64, JumpDword|DefaultSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk, { Disp32S }
 call, 1, 0xff, 0x2, 1, CpuNo64, Modrm|DefaultSize|No_bSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Reg16|Reg32|Word|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|JumpAbsolute }
 call, 1, 0xff, 0x2, 1, Cpu64, Modrm|DefaultSize|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk, { Reg16|Reg64|Word|Qword|Unspecified|BaseIndex|Disp8|Disp32|Disp32S|JumpAbsolute }
 // Intel Syntax
@@ -330,7 +331,8 @@ lcall, 2, 0x9a, None, 1, CpuNo64, JumpInterSegment|DefaultSize|No_bSuf|No_sSuf|N
 lcall, 1, 0xff, 0x3, 1, 0, Modrm|DefaultSize|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|JumpAbsolute }
 
 jmp, 1, 0xeb, None, 1, CpuNo64, Jump|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Disp8|Disp16|Disp32|Disp32S }
-jmp, 1, 0xeb, None, 1, Cpu64, Jump|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Disp8|Disp32S }
+jmp, 1, 0xeb, None, 1, Cpu64|CpuAMD64, Jump|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Disp8|Disp16|Disp32|Disp32S }
+jmp, 1, 0xeb, None, 1, Cpu64|CpuIntel64, Jump|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Disp8|Disp32S }
 jmp, 1, 0xff, 0x4, 1, CpuNo64, Modrm|No_bSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, { Reg16|Reg32|Word|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|JumpAbsolute }
 jmp, 1, 0xff, 0x4, 1, Cpu64, Modrm|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk, { Reg16|Reg64|Word|Qword|Unspecified|BaseIndex|Disp8|Disp32|Disp32S|JumpAbsolute }
 // Intel Syntax.

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Jan Beulich]

>>> On 15.05.15 at 18:52, <hjl.tools@gmail.com> wrote:
> * i386-opc.tbl: Add direct call/jmp with Disp16|Disp32 for AMD64.
> Mark direct call/jmp without Disp16|Disp32 as Intel64.

I had hoped that you wouldn't add back Disp32 to the AMD case, and
perhaps also that CpuAMD64 and CpuIntel64 would imply Cpu64 (as
their names already suggest).

Jan

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Mon, May 18, 2015 at 12:05 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 15.05.15 at 18:52, <hjl.tools@gmail.com> wrote:
>> * i386-opc.tbl: Add direct call/jmp with Disp16|Disp32 for AMD64.
>> Mark direct call/jmp without Disp16|Disp32 as Intel64.
>
> I had hoped that you wouldn't add back Disp32 to the AMD case, and

This is what I checked in.

> perhaps also that CpuAMD64 and CpuIntel64 would imply Cpu64 (as
> their names already suggest).

They are just a bit.  Make them to implement Cpu64 means adding more
codes to x86 assembler without any benefit.  If you can share with me
what you have in mind, I will see what I can do.

-- 
H.J.
----
* i386-opc.tbl: Remove Disp32 from AMD64 direct call/jmp.
* i386-init.h: Regenerated.
---
 opcodes/ChangeLog    | 5 +++++
 opcodes/i386-opc.tbl | 4 ++--
 opcodes/i386-tbl.h   | 4 ++--
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/opcodes/ChangeLog b/opcodes/ChangeLog
index d3f914c..ef05d2d 100644
--- a/opcodes/ChangeLog
+++ b/opcodes/ChangeLog
@@ -1,3 +1,8 @@
+2015-05-18  H.J. Lu  <hongjiu.lu@intel.com>
+
+ * i386-opc.tbl: Remove Disp32 from AMD64 direct call/jmp.
+ * i386-init.h: Regenerated.
+
 2015-05-15  H.J. Lu  <hongjiu.lu@intel.com>

  PR binutis/18386
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 56eddbf..42dcb56 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -319,7 +319,7 @@ shrd, 2, 0xfad, None, 2, Cpu386,
Modrm|CheckRegSize|No_bSuf|No_sSuf|No_ldSuf, {

 // Control transfer instructions.
 call, 1, 0xe8, None, 1, CpuNo64,
JumpDword|DefaultSize|No_bSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, {
Disp16|Disp32 }
-call, 1, 0xe8, None, 1, Cpu64|CpuAMD64,
JumpDword|DefaultSize|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk,
{ Disp16|Disp32|Disp32S }
+call, 1, 0xe8, None, 1, Cpu64|CpuAMD64,
JumpDword|DefaultSize|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk,
{ Disp16|Disp32S }
 call, 1, 0xe8, None, 1, Cpu64|CpuIntel64,
JumpDword|DefaultSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk,
{ Disp32S }
 call, 1, 0xff, 0x2, 1, CpuNo64,
Modrm|DefaultSize|No_bSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, {
Reg16|Reg32|Word|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|JumpAbsolute
}
 call, 1, 0xff, 0x2, 1, Cpu64,
Modrm|DefaultSize|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk,
{ Reg16|Reg64|Word|Qword|Unspecified|BaseIndex|Disp8|Disp32|Disp32S|JumpAbsolute
}
@@ -331,7 +331,7 @@ lcall, 2, 0x9a, None, 1, CpuNo64,
JumpInterSegment|DefaultSize|No_bSuf|No_sSuf|N
 lcall, 1, 0xff, 0x3, 1, 0,
Modrm|DefaultSize|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, {
Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|JumpAbsolute }

 jmp, 1, 0xeb, None, 1, CpuNo64,
Jump|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, {
Disp8|Disp16|Disp32|Disp32S }
-jmp, 1, 0xeb, None, 1, Cpu64|CpuAMD64,
Jump|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, {
Disp8|Disp16|Disp32|Disp32S }
+jmp, 1, 0xeb, None, 1, Cpu64|CpuAMD64,
Jump|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, {
Disp8|Disp16|Disp32S }
 jmp, 1, 0xeb, None, 1, Cpu64|CpuIntel64,
Jump|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, {
Disp8|Disp32S }
 jmp, 1, 0xff, 0x4, 1, CpuNo64,
Modrm|No_bSuf|No_sSuf|No_qSuf|No_ldSuf|BNDPrefixOk, {
Reg16|Reg32|Word|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|JumpAbsolute
}
 jmp, 1, 0xff, 0x4, 1, Cpu64,
Modrm|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64|BNDPrefixOk, {
Reg16|Reg64|Word|Qword|Unspecified|BaseIndex|Disp8|Disp32|Disp32S|JumpAbsolute
}

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[Jan Beulich]

>>> On 18.05.15 at 13:22, <hjl.tools@gmail.com> wrote:
> On Mon, May 18, 2015 at 12:05 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 15.05.15 at 18:52, <hjl.tools@gmail.com> wrote:
>>> * i386-opc.tbl: Add direct call/jmp with Disp16|Disp32 for AMD64.
>>> Mark direct call/jmp without Disp16|Disp32 as Intel64.
>>
>> I had hoped that you wouldn't add back Disp32 to the AMD case, and
> 
> This is what I checked in.

Thanks!

>> perhaps also that CpuAMD64 and CpuIntel64 would imply Cpu64 (as
>> their names already suggest).
> 
> They are just a bit.  Make them to implement Cpu64 means adding more
> codes to x86 assembler without any benefit.  If you can share with me
> what you have in mind, I will see what I can do.

Ah, no, I didn't mean the assembler to do more work. Instead I
thought that the generator utility could set Cpu64 alongside either
of the new ones, thus keeping the opcode table slightly better
readable.

Jan

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

[H.J. Lu]

On Mon, May 18, 2015 at 4:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> perhaps also that CpuAMD64 and CpuIntel64 would imply Cpu64 (as
>>> their names already suggest).
>>
>> They are just a bit.  Make them to implement Cpu64 means adding more
>> codes to x86 assembler without any benefit.  If you can share with me
>> what you have in mind, I will see what I can do.
>
> Ah, no, I didn't mean the assembler to do more work. Instead I
> thought that the generator utility could set Cpu64 alongside either
> of the new ones, thus keeping the opcode table slightly better
> readable.

Sure. We will do that when we add CPU_AMD64_FLAGS, like:

  { "CPU_AMD64_FLAGS",
    "CpuAMD64|Cpu64" },

I haven't found a need for it yet.

-- 
H.J.