[PATCH 0/5] x86: (mainly) limit suffix emission for stack accessing and branch insns

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Jan Beulich-2
On 16.07.2020 13:38, H.J. Lu wrote:

> On Thu, Jul 16, 2020 at 2:53 AM Jan Beulich <[hidden email]> wrote:
>>
>> On 15.07.2020 16:02, H.J. Lu wrote:
>>> On Tue, Jul 14, 2020 at 11:08 PM Jan Beulich <[hidden email]> wrote:
>>>>
>>>> On 14.07.2020 14:59, H.J. Lu wrote:
>>>>> On Tue, Jul 14, 2020 at 5:47 AM Jan Beulich <[hidden email]> wrote:
>>>>>>
>>>>>> On 14.07.2020 14:36, H.J. Lu wrote:
>>>>>>> On Tue, Jul 14, 2020 at 5:20 AM Jan Beulich <[hidden email]> 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 <[hidden email]> 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.
>>>>
>>>
>>> We should use a prefix which can be processed by assembler.
>>> {dispXX} tells assembler to prefer a specific displacement size.
>>
>> Funny you should say this: There's no {disp16}. And the assembler
>> understands (to a certain degree, but this got improved recently)
>> data16 / data32. IOW yet another argument towards data16 / data32,
>> if we are to go this route in the first place (which right now is
>> only the fallback in case allowing the suffixes in the assembler
>> causes overly difficult problems, and which continues to pend your
>> response to me pointing out that emitting _prefixes_ is not in
>> line with _suffix_ in -Msuffix).
>>
>
> If needed, we can add {disp16}.

I've been having this on my todo list for quite some time already,
but not because of the considerations here.

What I don't understand is why you _still_ don't answer the question
raised: Do you really think -Msuffix should lead to output like

        {disp32} jmp label

? I could see {dispNN} to have advantages over data16/data32, but
that's independent of -Msuffix, i.e. the prefix would be printed
only if a non-default displacement width was in effect. Printing
{dispNN} for all JMP / CALL / Jcc in suffix-always mode seems like
an extreme form of clutter to me. (As a follow-on to this, we then
ought to also always print {dispNN} for memory accesses with a
word-sized displacement [albeit presumably limited to the no-base-
and-no-index case] - yet more clutter.)

Jan
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - binutils list mailing list
On Thu, Jul 16, 2020 at 4:57 AM Jan Beulich <[hidden email]> wrote:

>
> On 16.07.2020 13:38, H.J. Lu wrote:
> > On Thu, Jul 16, 2020 at 2:53 AM Jan Beulich <[hidden email]> wrote:
> >>
> >> On 15.07.2020 16:02, H.J. Lu wrote:
> >>> On Tue, Jul 14, 2020 at 11:08 PM Jan Beulich <[hidden email]> wrote:
> >>>>
> >>>> On 14.07.2020 14:59, H.J. Lu wrote:
> >>>>> On Tue, Jul 14, 2020 at 5:47 AM Jan Beulich <[hidden email]> wrote:
> >>>>>>
> >>>>>> On 14.07.2020 14:36, H.J. Lu wrote:
> >>>>>>> On Tue, Jul 14, 2020 at 5:20 AM Jan Beulich <[hidden email]> 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 <[hidden email]> 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.
> >>>>
> >>>
> >>> We should use a prefix which can be processed by assembler.
> >>> {dispXX} tells assembler to prefer a specific displacement size.
> >>
> >> Funny you should say this: There's no {disp16}. And the assembler
> >> understands (to a certain degree, but this got improved recently)
> >> data16 / data32. IOW yet another argument towards data16 / data32,
> >> if we are to go this route in the first place (which right now is
> >> only the fallback in case allowing the suffixes in the assembler
> >> causes overly difficult problems, and which continues to pend your
> >> response to me pointing out that emitting _prefixes_ is not in
> >> line with _suffix_ in -Msuffix).
> >>
> >
> > If needed, we can add {disp16}.
>
> I've been having this on my todo list for quite some time already,
> but not because of the considerations here.
>
> What I don't understand is why you _still_ don't answer the question
> raised: Do you really think -Msuffix should lead to output like
>
>         {disp32} jmp label
>
> ? I could see {dispNN} to have advantages over data16/data32, but
> that's independent of -Msuffix, i.e. the prefix would be printed
> only if a non-default displacement width was in effect. Printing
> {dispNN} for all JMP / CALL / Jcc in suffix-always mode seems like
> an extreme form of clutter to me. (As a follow-on to this, we then
> ought to also always print {dispNN} for memory accesses with a
> word-sized displacement [albeit presumably limited to the no-base-
> and-no-index case] - yet more clutter.)
>

We are inventing things to distinguish different displacement sizes for
branch instructions.  I prefer {disp16} over data16/data32.  We only
need to do it for branch instructions with -Msuffix or with a new option.

--
H.J.
12