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

["H.J. Lu" <hjl.tools@gmail.com>]

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.