[PATCH 4/5] x86-64: Intel64 adjustments for conditional jumps
H.J. Lu
hjl.tools@gmail.com
Wed Jul 15 14:02:14 GMT 2020
On Tue, Jul 14, 2020 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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.
>
We should use a prefix which can be processed by assembler.
{dispXX} tells assembler to prefer a specific displacement size.
--
H.J.
More information about the Binutils
mailing list