[PATCH 4/5] x86-64: Intel64 adjustments for conditional jumps

[Jan Beulich]

On 14.07.2020 14:59, H.J. Lu wrote:
> On Tue, Jul 14, 2020 at 5:47 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 14.07.2020 14:36, H.J. Lu wrote:
>>> On Tue, Jul 14, 2020 at 5:20 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 14.07.2020 14:18, Jan Beulich wrote:
>>>>> On 14.07.2020 14:00, H.J. Lu wrote:
>>>>>> On Tue, Jul 14, 2020 at 3:13 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>> --- a/gas/testsuite/gas/i386/opcode-suffix.d
>>>>>>> +++ b/gas/testsuite/gas/i386/opcode-suffix.d
>>>>>>> @@ -305,22 +305,22 @@ Disassembly of section .text:
>>>>>>>   *[0-9a-f]+:   0f 77[  ]+emms[         ]+
>>>>>>>   *[0-9a-f]+:   0f 7e 90 90 90 90 90[   ]+movd[         ]+%mm2,-0x6f6f6f70\(%eax\)
>>>>>>>   *[0-9a-f]+:   0f 7f 90 90 90 90 90[   ]+movq[         ]+%mm2,-0x6f6f6f70\(%eax\)
>>>>>>> - *[0-9a-f]+:   0f 80 90 90 90 90[      ]+jo[   ]+909094e2 <foo\+0x909094e2>
>>>>>>> - *[0-9a-f]+:   0f 81 90 90 90 90[      ]+jno[  ]+909094e8 <foo\+0x909094e8>
>>>>>>> - *[0-9a-f]+:   0f 82 90 90 90 90[      ]+jb[   ]+909094ee <foo\+0x909094ee>
>>>>>>> - *[0-9a-f]+:   0f 83 90 90 90 90[      ]+jae[  ]+909094f4 <foo\+0x909094f4>
>>>>>>> - *[0-9a-f]+:   0f 84 90 90 90 90[      ]+je[   ]+909094fa <foo\+0x909094fa>
>>>>>>> - *[0-9a-f]+:   0f 85 90 90 90 90[      ]+jne[  ]+90909500 <foo\+0x90909500>
>>>>>>> - *[0-9a-f]+:   0f 86 90 90 90 90[      ]+jbe[  ]+90909506 <foo\+0x90909506>
>>>>>>> - *[0-9a-f]+:   0f 87 90 90 90 90[      ]+ja[   ]+9090950c <foo\+0x9090950c>
>>>>>>> - *[0-9a-f]+:   0f 88 90 90 90 90[      ]+js[   ]+90909512 <foo\+0x90909512>
>>>>>>> - *[0-9a-f]+:   0f 89 90 90 90 90[      ]+jns[  ]+90909518 <foo\+0x90909518>
>>>>>>> - *[0-9a-f]+:   0f 8a 90 90 90 90[      ]+jp[   ]+9090951e <foo\+0x9090951e>
>>>>>>> - *[0-9a-f]+:   0f 8b 90 90 90 90[      ]+jnp[  ]+90909524 <foo\+0x90909524>
>>>>>>> - *[0-9a-f]+:   0f 8c 90 90 90 90[      ]+jl[   ]+9090952a <foo\+0x9090952a>
>>>>>>> - *[0-9a-f]+:   0f 8d 90 90 90 90[      ]+jge[  ]+90909530 <foo\+0x90909530>
>>>>>>> - *[0-9a-f]+:   0f 8e 90 90 90 90[      ]+jle[  ]+90909536 <foo\+0x90909536>
>>>>>>> - *[0-9a-f]+:   0f 8f 90 90 90 90[      ]+jg[   ]+9090953c <foo\+0x9090953c>
>>>>>>> + *[0-9a-f]+:   0f 80 90 90 90 90[      ]+jol[  ]+909094e2 <foo\+0x909094e2>
>>>>>>> + *[0-9a-f]+:   0f 81 90 90 90 90[      ]+jnol[         ]+909094e8 <foo\+0x909094e8>
>>>>>>> + *[0-9a-f]+:   0f 82 90 90 90 90[      ]+jbl[  ]+909094ee <foo\+0x909094ee>
>>>>>>> + *[0-9a-f]+:   0f 83 90 90 90 90[      ]+jael[         ]+909094f4 <foo\+0x909094f4>
>>>>>>> + *[0-9a-f]+:   0f 84 90 90 90 90[      ]+jel[  ]+909094fa <foo\+0x909094fa>
>>>>>>> + *[0-9a-f]+:   0f 85 90 90 90 90[      ]+jnel[         ]+90909500 <foo\+0x90909500>
>>>>>>> + *[0-9a-f]+:   0f 86 90 90 90 90[      ]+jbel[         ]+90909506 <foo\+0x90909506>
>>>>>>> + *[0-9a-f]+:   0f 87 90 90 90 90[      ]+jal[  ]+9090950c <foo\+0x9090950c>
>>>>>>> + *[0-9a-f]+:   0f 88 90 90 90 90[      ]+jsl[  ]+90909512 <foo\+0x90909512>
>>>>>>> + *[0-9a-f]+:   0f 89 90 90 90 90[      ]+jnsl[         ]+90909518 <foo\+0x90909518>
>>>>>>> + *[0-9a-f]+:   0f 8a 90 90 90 90[      ]+jpl[  ]+9090951e <foo\+0x9090951e>
>>>>>>> + *[0-9a-f]+:   0f 8b 90 90 90 90[      ]+jnpl[         ]+90909524 <foo\+0x90909524>
>>>>>>> + *[0-9a-f]+:   0f 8c 90 90 90 90[      ]+jll[  ]+9090952a <foo\+0x9090952a>
>>>>>>> + *[0-9a-f]+:   0f 8d 90 90 90 90[      ]+jgel[         ]+90909530 <foo\+0x90909530>
>>>>>>> + *[0-9a-f]+:   0f 8e 90 90 90 90[      ]+jlel[         ]+90909536 <foo\+0x90909536>
>>>>>>> + *[0-9a-f]+:   0f 8f 90 90 90 90[      ]+jgl[  ]+9090953c <foo\+0x9090953c>
>>>>>>>   *[0-9a-f]+:   0f 90 80 90 90 90 90[   ]+seto[         ]+-0x6f6f6f70\(%eax\)
>>>>>>>   *[0-9a-f]+:   0f 91 80 90 90 90 90[   ]+setno[        ]+-0x6f6f6f70\(%eax\)
>>>>>>>   *[0-9a-f]+:   0f 92 80 90 90 90 90[   ]+setb[         ]+-0x6f6f6f70\(%eax\)
>>>>>>
>>>>>> There are instructions like jl and jnl.  Will assembler properly
>>>>>> handle `l' as a suffix here?
>>>>>
>>>>> j<cc> as well as jmp (with displacement) have No_lSuf set, so won't
>>>>> accept l suffixes (same for the w one). Nevertheless already prior
>>>>> to this change the disassembler will produce "jmpl" (and "jmpw").
>>>>> IOW a disagreement between disassembler and assembler already exists.
>>>
>>> We should avoid it as much as we can.
>>>
>>>>>> If we do need to distinguish them, can we generate {disp32} pseudo prefix
>>>>>> instead?
>>>>>
>>>>> We could, but then consistently for Jcc, JMP, and CALL. But how is
>>>>> emitting a pseudo-prefix in line with the name of the controlling
>>>>> command line option "-Msuffix"?
>>>
>>> That works for me.
>>
>> Okay, but you didn't answer my question.
> 
> We can always generate pseudo prefix.

But my question was towards "prefix" != "suffix".

>>>> FAOD to achieve consistency I think the preferred route would then
>>>> be for the assembler to accept l and w suffixes for Jcc and JMP.
>>>> Not sure though what fallout this may mean.
>>>
>>> That could be quite messy.
>>
>> I guess I'd still prefer to try that first, and resort to the
>> alternative only if it really turns out to be.
> 
> Please give it a try.
> 
>>>  I think pseudo prefix is much less invasive.
>>
>> Maybe to the disassembler; I'm less sure about the testsuites of both
>> gas and ld.
>>
>> Actually - if we were to go this route, then why pseudo prefixes in
>> the first place? We already emit data{16,32} prefixes for other
>> reasons, so we could do so here as well in place of the suffixes.
> 
> There is data32 prefix.  But there is no disp32 prefix.  I call it
> pseudo prefix.

But the prefix _is_ a data size override, i.e. data{16,32} _is_ what
we want to express. My question here is why to invent yet another
prefix when we already have a suitable one.

Jan