x86-64-branch-3 test case

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

x86-64-branch-3 test case

Jan Beulich-2
H.J.,

in the course of addressing bug 24546 I'd once again stumbled across
this test, and in particular its entirely wrong expectations (aiui):
The notation "jmp symbol" expresses a direct jump, not an indirect
one. Adding any kind of prefix should not alter this. And a near
branch ("jmp" doesn't stand for far ones in AT&T syntax) should in
no case then even become a far branch encoding. Imo the correct
course of action by the assembler would be to either warn about
and drop the bogus (in Intel64 mode) prefix, or keep it as benign,
but still emit a direct branch encoding with a 32-bit displacement.

Thoughts?

For background: These are the intended new templates:

// Intel Syntax remaining jmp instances.
jmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
jmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Unspecified|BaseIndex }
jmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Tbyte|Unspecified|BaseIndex }
ljmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
ljmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex }
ljmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

It's the Cpu64 here which causes things to break: i386-gen infers
no Disp16 in this case from BaseIndex, and hence the Disp16
generated in i.types[0] won't match in Intel64 mode (but as said
above imo there shouldn't have been a match even before my
changes). And of course i386_displacement() has its own issues
when considering the case of us assuming (with a warning) an
indirect branch even when not indicated so by '*' if no better
match can be found.

I assume it goes without saying that once I make the Cpu64 case
work correctly here, and if not going the match-the-direct-jmp
route as suggested above, the match would then be with the near
indirect jmp (which right now doesn't match just because of it
having Cpu64 on its template, as per above). IOW the generated
code here will change no matter what.

Thanks, Jan
Reply | Threaded
Open this post in threaded view
|

Re: x86-64-branch-3 test case

H.J. Lu-30
On Fri, Dec 13, 2019 at 1:39 AM Jan Beulich <[hidden email]> wrote:

>
> H.J.,
>
> in the course of addressing bug 24546 I'd once again stumbled across
> this test, and in particular its entirely wrong expectations (aiui):
> The notation "jmp symbol" expresses a direct jump, not an indirect
> one. Adding any kind of prefix should not alter this. And a near
> branch ("jmp" doesn't stand for far ones in AT&T syntax) should in
> no case then even become a far branch encoding. Imo the correct
> course of action by the assembler would be to either warn about
> and drop the bogus (in Intel64 mode) prefix, or keep it as benign,
> but still emit a direct branch encoding with a 32-bit displacement.

Did you mean "suffix"?  Will it implement m16:m64 in 64-bit mode
for Intel64?

> Thoughts?
>
> For background: These are the intended new templates:
>
> // Intel Syntax remaining jmp instances.
> jmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
> jmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Unspecified|BaseIndex }
> jmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Tbyte|Unspecified|BaseIndex }
> ljmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
> ljmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex }
> ljmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }
>
> It's the Cpu64 here which causes things to break: i386-gen infers
> no Disp16 in this case from BaseIndex, and hence the Disp16
> generated in i.types[0] won't match in Intel64 mode (but as said
> above imo there shouldn't have been a match even before my
> changes). And of course i386_displacement() has its own issues
> when considering the case of us assuming (with a warning) an
> indirect branch even when not indicated so by '*' if no better
> match can be found.
>
> I assume it goes without saying that once I make the Cpu64 case
> work correctly here, and if not going the match-the-direct-jmp
> route as suggested above, the match would then be with the near
> indirect jmp (which right now doesn't match just because of it
> having Cpu64 on its template, as per above). IOW the generated
> code here will change no matter what.
>

If we want to support m16:m64 for Intel64, what syntax do we want
to use in AT&T syntax?  If it makes assembler more complex, we
should leave it alone since it doesn't bring much benefit.

Thanks.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: x86-64-branch-3 test case

Jan Beulich-2
On 13.12.2019 17:09,  H.J. Lu  wrote:

> On Fri, Dec 13, 2019 at 1:39 AM Jan Beulich <[hidden email]> wrote:
>>
>> H.J.,
>>
>> in the course of addressing bug 24546 I'd once again stumbled across
>> this test, and in particular its entirely wrong expectations (aiui):
>> The notation "jmp symbol" expresses a direct jump, not an indirect
>> one. Adding any kind of prefix should not alter this. And a near
>> branch ("jmp" doesn't stand for far ones in AT&T syntax) should in
>> no case then even become a far branch encoding. Imo the correct
>> course of action by the assembler would be to either warn about
>> and drop the bogus (in Intel64 mode) prefix, or keep it as benign,
>> but still emit a direct branch encoding with a 32-bit displacement.
>
> Did you mean "suffix"?  Will it implement m16:m64 in 64-bit mode
> for Intel64?

I did mean "prefix" (the data16 one). And yes, it'll permit the
m16:m64 form, just like LFS et al already allow.

>> Thoughts?
>>
>> For background: These are the intended new templates:
>>
>> // Intel Syntax remaining jmp instances.
>> jmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
>> jmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Unspecified|BaseIndex }
>> jmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Tbyte|Unspecified|BaseIndex }
>> ljmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
>> ljmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex }
>> ljmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }
>>
>> It's the Cpu64 here which causes things to break: i386-gen infers
>> no Disp16 in this case from BaseIndex, and hence the Disp16
>> generated in i.types[0] won't match in Intel64 mode (but as said
>> above imo there shouldn't have been a match even before my
>> changes). And of course i386_displacement() has its own issues
>> when considering the case of us assuming (with a warning) an
>> indirect branch even when not indicated so by '*' if no better
>> match can be found.
>>
>> I assume it goes without saying that once I make the Cpu64 case
>> work correctly here, and if not going the match-the-direct-jmp
>> route as suggested above, the match would then be with the near
>> indirect jmp (which right now doesn't match just because of it
>> having Cpu64 on its template, as per above). IOW the generated
>> code here will change no matter what.
>>
>
> If we want to support m16:m64 for Intel64, what syntax do we want
> to use in AT&T syntax?  If it makes assembler more complex, we
> should leave it alone since it doesn't bring much benefit.

lcallq / ljmpq will be the obvious mnemonics to use for AT&T mode.
I didn't even think there was any question in this regard.

Jan
Reply | Threaded
Open this post in threaded view
|

Re: x86-64-branch-3 test case

H.J. Lu-30
On Fri, Dec 13, 2019 at 9:02 AM Jan Beulich <[hidden email]> wrote:

>
> On 13.12.2019 17:09,  H.J. Lu  wrote:
> > On Fri, Dec 13, 2019 at 1:39 AM Jan Beulich <[hidden email]> wrote:
> >>
> >> H.J.,
> >>
> >> in the course of addressing bug 24546 I'd once again stumbled across
> >> this test, and in particular its entirely wrong expectations (aiui):
> >> The notation "jmp symbol" expresses a direct jump, not an indirect
> >> one. Adding any kind of prefix should not alter this. And a near
> >> branch ("jmp" doesn't stand for far ones in AT&T syntax) should in
> >> no case then even become a far branch encoding. Imo the correct
> >> course of action by the assembler would be to either warn about
> >> and drop the bogus (in Intel64 mode) prefix, or keep it as benign,
> >> but still emit a direct branch encoding with a 32-bit displacement.
> >
> > Did you mean "suffix"?  Will it implement m16:m64 in 64-bit mode
> > for Intel64?
>
> I did mean "prefix" (the data16 one). And yes, it'll permit the
> m16:m64 form, just like LFS et al already allow.
>
> >> Thoughts?
> >>
> >> For background: These are the intended new templates:
> >>
> >> // Intel Syntax remaining jmp instances.
> >> jmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
> >> jmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Unspecified|BaseIndex }
> >> jmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Tbyte|Unspecified|BaseIndex }
> >> ljmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
> >> ljmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex }
> >> ljmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }
> >>
> >> It's the Cpu64 here which causes things to break: i386-gen infers
> >> no Disp16 in this case from BaseIndex, and hence the Disp16
> >> generated in i.types[0] won't match in Intel64 mode (but as said
> >> above imo there shouldn't have been a match even before my
> >> changes). And of course i386_displacement() has its own issues
> >> when considering the case of us assuming (with a warning) an
> >> indirect branch even when not indicated so by '*' if no better
> >> match can be found.
> >>
> >> I assume it goes without saying that once I make the Cpu64 case
> >> work correctly here, and if not going the match-the-direct-jmp
> >> route as suggested above, the match would then be with the near
> >> indirect jmp (which right now doesn't match just because of it
> >> having Cpu64 on its template, as per above). IOW the generated
> >> code here will change no matter what.
> >>
> >
> > If we want to support m16:m64 for Intel64, what syntax do we want
> > to use in AT&T syntax?  If it makes assembler more complex, we
> > should leave it alone since it doesn't bring much benefit.
>
> lcallq / ljmpq will be the obvious mnemonics to use for AT&T mode.
> I didn't even think there was any question in this regard.
>

Please put your proposed syntax in the bug report.   On the other
hand, I don't think it will get much use.


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: x86-64-branch-3 test case

Jan Beulich-2
On 14.12.2019 20:50, H.J. Lu wrote:

> On Fri, Dec 13, 2019 at 9:02 AM Jan Beulich <[hidden email]> wrote:
>>
>> On 13.12.2019 17:09,  H.J. Lu  wrote:
>>> On Fri, Dec 13, 2019 at 1:39 AM Jan Beulich <[hidden email]> wrote:
>>>>
>>>> H.J.,
>>>>
>>>> in the course of addressing bug 24546 I'd once again stumbled across
>>>> this test, and in particular its entirely wrong expectations (aiui):
>>>> The notation "jmp symbol" expresses a direct jump, not an indirect
>>>> one. Adding any kind of prefix should not alter this. And a near
>>>> branch ("jmp" doesn't stand for far ones in AT&T syntax) should in
>>>> no case then even become a far branch encoding. Imo the correct
>>>> course of action by the assembler would be to either warn about
>>>> and drop the bogus (in Intel64 mode) prefix, or keep it as benign,
>>>> but still emit a direct branch encoding with a 32-bit displacement.
>>>
>>> Did you mean "suffix"?  Will it implement m16:m64 in 64-bit mode
>>> for Intel64?
>>
>> I did mean "prefix" (the data16 one). And yes, it'll permit the
>> m16:m64 form, just like LFS et al already allow.
>>
>>>> Thoughts?

May I ask that we make progress with the actual issue at hand, rather
than discussing the 2nd step before the 1st? The $subject test case is
definitely bogus (and likely another result of putting in expectations
matching what the assembler happens to produce at a given point in
time, rather than having them express how things ought to be, fixing
the code if need be). The question is which of the two possible
behaviors we want to go with; for consistency with other code I think
keeping (emitting) the requested (but ignored by hardware) prefix is
the better model.

>>>> For background: These are the intended new templates:
>>>>
>>>> // Intel Syntax remaining jmp instances.
>>>> jmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
>>>> jmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Unspecified|BaseIndex }
>>>> jmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Tbyte|Unspecified|BaseIndex }
>>>> ljmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
>>>> ljmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex }
>>>> ljmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }
>>>>
>>>> It's the Cpu64 here which causes things to break: i386-gen infers
>>>> no Disp16 in this case from BaseIndex, and hence the Disp16
>>>> generated in i.types[0] won't match in Intel64 mode (but as said
>>>> above imo there shouldn't have been a match even before my
>>>> changes). And of course i386_displacement() has its own issues
>>>> when considering the case of us assuming (with a warning) an
>>>> indirect branch even when not indicated so by '*' if no better
>>>> match can be found.
>>>>
>>>> I assume it goes without saying that once I make the Cpu64 case
>>>> work correctly here, and if not going the match-the-direct-jmp
>>>> route as suggested above, the match would then be with the near
>>>> indirect jmp (which right now doesn't match just because of it
>>>> having Cpu64 on its template, as per above). IOW the generated
>>>> code here will change no matter what.
>>>>
>>>
>>> If we want to support m16:m64 for Intel64, what syntax do we want
>>> to use in AT&T syntax?  If it makes assembler more complex, we
>>> should leave it alone since it doesn't bring much benefit.
>>
>> lcallq / ljmpq will be the obvious mnemonics to use for AT&T mode.
>> I didn't even think there was any question in this regard.
>>
>
> Please put your proposed syntax in the bug report.   On the other
> hand, I don't think it will get much use.

I don't understand - what need would there be to have this there,
the more that it's entirely expected that it would be this way
(paralleling ljmpw/ljmpl and lcallw/lcalll)? I could understand
your request if there was something unexpected or counter-
intuitive to happen. (As to "not much use" - I take it Andrew
entered the bug for a reason.)

Jan
Reply | Threaded
Open this post in threaded view
|

Re: x86-64-branch-3 test case

H.J. Lu-30
On Mon, Dec 16, 2019 at 2:31 AM Jan Beulich <[hidden email]> wrote:

>
> On 14.12.2019 20:50, H.J. Lu wrote:
> > On Fri, Dec 13, 2019 at 9:02 AM Jan Beulich <[hidden email]> wrote:
> >>
> >> On 13.12.2019 17:09,  H.J. Lu  wrote:
> >>> On Fri, Dec 13, 2019 at 1:39 AM Jan Beulich <[hidden email]> wrote:
> >>>>
> >>>> H.J.,
> >>>>
> >>>> in the course of addressing bug 24546 I'd once again stumbled across
> >>>> this test, and in particular its entirely wrong expectations (aiui):
> >>>> The notation "jmp symbol" expresses a direct jump, not an indirect
> >>>> one. Adding any kind of prefix should not alter this. And a near
> >>>> branch ("jmp" doesn't stand for far ones in AT&T syntax) should in
> >>>> no case then even become a far branch encoding. Imo the correct
> >>>> course of action by the assembler would be to either warn about
> >>>> and drop the bogus (in Intel64 mode) prefix, or keep it as benign,
> >>>> but still emit a direct branch encoding with a 32-bit displacement.
> >>>
> >>> Did you mean "suffix"?  Will it implement m16:m64 in 64-bit mode
> >>> for Intel64?
> >>
> >> I did mean "prefix" (the data16 one). And yes, it'll permit the
> >> m16:m64 form, just like LFS et al already allow.
> >>
> >>>> Thoughts?
>
> May I ask that we make progress with the actual issue at hand, rather
> than discussing the 2nd step before the 1st? The $subject test case is
> definitely bogus (and likely another result of putting in expectations
> matching what the assembler happens to produce at a given point in
> time, rather than having them express how things ought to be, fixing
> the code if need be). The question is which of the two possible
> behaviors we want to go with; for consistency with other code I think
> keeping (emitting) the requested (but ignored by hardware) prefix is
> the better model.
>
> >>>> For background: These are the intended new templates:
> >>>>
> >>>> // Intel Syntax remaining jmp instances.
> >>>> jmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
> >>>> jmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Unspecified|BaseIndex }
> >>>> jmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Tbyte|Unspecified|BaseIndex }
> >>>> ljmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
> >>>> ljmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex }
> >>>> ljmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }
> >>>>
> >>>> It's the Cpu64 here which causes things to break: i386-gen infers
> >>>> no Disp16 in this case from BaseIndex, and hence the Disp16
> >>>> generated in i.types[0] won't match in Intel64 mode (but as said
> >>>> above imo there shouldn't have been a match even before my
> >>>> changes). And of course i386_displacement() has its own issues
> >>>> when considering the case of us assuming (with a warning) an
> >>>> indirect branch even when not indicated so by '*' if no better
> >>>> match can be found.
> >>>>
> >>>> I assume it goes without saying that once I make the Cpu64 case
> >>>> work correctly here, and if not going the match-the-direct-jmp
> >>>> route as suggested above, the match would then be with the near
> >>>> indirect jmp (which right now doesn't match just because of it
> >>>> having Cpu64 on its template, as per above). IOW the generated
> >>>> code here will change no matter what.
> >>>>
> >>>
> >>> If we want to support m16:m64 for Intel64, what syntax do we want
> >>> to use in AT&T syntax?  If it makes assembler more complex, we
> >>> should leave it alone since it doesn't bring much benefit.
> >>
> >> lcallq / ljmpq will be the obvious mnemonics to use for AT&T mode.
> >> I didn't even think there was any question in this regard.
> >>
> >
> > Please put your proposed syntax in the bug report.   On the other
> > hand, I don't think it will get much use.
>
> I don't understand - what need would there be to have this there,
> the more that it's entirely expected that it would be this way
> (paralleling ljmpw/ljmpl and lcallw/lcalll)? I could understand
> your request if there was something unexpected or counter-
> intuitive to happen. (As to "not much use" - I take it Andrew
> entered the bug for a reason.)
>

GAS has been this way for a long time.  We have a very good
reason to change it.


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: x86-64-branch-3 test case

Jan Beulich-2
On 08.01.2020 23:45, H.J. Lu wrote:

> On Mon, Dec 16, 2019 at 2:31 AM Jan Beulich <[hidden email]> wrote:
>>
>> On 14.12.2019 20:50, H.J. Lu wrote:
>>> On Fri, Dec 13, 2019 at 9:02 AM Jan Beulich <[hidden email]> wrote:
>>>>
>>>> On 13.12.2019 17:09,  H.J. Lu  wrote:
>>>>> On Fri, Dec 13, 2019 at 1:39 AM Jan Beulich <[hidden email]> wrote:
>>>>>>
>>>>>> H.J.,
>>>>>>
>>>>>> in the course of addressing bug 24546 I'd once again stumbled across
>>>>>> this test, and in particular its entirely wrong expectations (aiui):
>>>>>> The notation "jmp symbol" expresses a direct jump, not an indirect
>>>>>> one. Adding any kind of prefix should not alter this. And a near
>>>>>> branch ("jmp" doesn't stand for far ones in AT&T syntax) should in
>>>>>> no case then even become a far branch encoding. Imo the correct
>>>>>> course of action by the assembler would be to either warn about
>>>>>> and drop the bogus (in Intel64 mode) prefix, or keep it as benign,
>>>>>> but still emit a direct branch encoding with a 32-bit displacement.
>>>>>
>>>>> Did you mean "suffix"?  Will it implement m16:m64 in 64-bit mode
>>>>> for Intel64?
>>>>
>>>> I did mean "prefix" (the data16 one). And yes, it'll permit the
>>>> m16:m64 form, just like LFS et al already allow.
>>>>
>>>>>> Thoughts?
>>
>> May I ask that we make progress with the actual issue at hand, rather
>> than discussing the 2nd step before the 1st? The $subject test case is
>> definitely bogus (and likely another result of putting in expectations
>> matching what the assembler happens to produce at a given point in
>> time, rather than having them express how things ought to be, fixing
>> the code if need be). The question is which of the two possible
>> behaviors we want to go with; for consistency with other code I think
>> keeping (emitting) the requested (but ignored by hardware) prefix is
>> the better model.
>>
>>>>>> For background: These are the intended new templates:
>>>>>>
>>>>>> // Intel Syntax remaining jmp instances.
>>>>>> jmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
>>>>>> jmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Unspecified|BaseIndex }
>>>>>> jmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Tbyte|Unspecified|BaseIndex }
>>>>>> ljmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
>>>>>> ljmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex }
>>>>>> ljmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }
>>>>>>
>>>>>> It's the Cpu64 here which causes things to break: i386-gen infers
>>>>>> no Disp16 in this case from BaseIndex, and hence the Disp16
>>>>>> generated in i.types[0] won't match in Intel64 mode (but as said
>>>>>> above imo there shouldn't have been a match even before my
>>>>>> changes). And of course i386_displacement() has its own issues
>>>>>> when considering the case of us assuming (with a warning) an
>>>>>> indirect branch even when not indicated so by '*' if no better
>>>>>> match can be found.
>>>>>>
>>>>>> I assume it goes without saying that once I make the Cpu64 case
>>>>>> work correctly here, and if not going the match-the-direct-jmp
>>>>>> route as suggested above, the match would then be with the near
>>>>>> indirect jmp (which right now doesn't match just because of it
>>>>>> having Cpu64 on its template, as per above). IOW the generated
>>>>>> code here will change no matter what.
>>>>>>
>>>>>
>>>>> If we want to support m16:m64 for Intel64, what syntax do we want
>>>>> to use in AT&T syntax?  If it makes assembler more complex, we
>>>>> should leave it alone since it doesn't bring much benefit.
>>>>
>>>> lcallq / ljmpq will be the obvious mnemonics to use for AT&T mode.
>>>> I didn't even think there was any question in this regard.
>>>>
>>>
>>> Please put your proposed syntax in the bug report.   On the other
>>> hand, I don't think it will get much use.
>>
>> I don't understand - what need would there be to have this there,
>> the more that it's entirely expected that it would be this way
>> (paralleling ljmpw/ljmpl and lcallw/lcalll)? I could understand
>> your request if there was something unexpected or counter-
>> intuitive to happen. (As to "not much use" - I take it Andrew
>> entered the bug for a reason.)
>>
>
> GAS has been this way for a long time.  We have a very good
> reason to change it.

If you were talking about changing something which worked before,
I'd agree. If the extension would be kind of unexpected, I'd
agree too. But in the series I've meanwhile posted I'm only
making something work (in the regard to lcall/ljmp) which
previously didn't work at all (q suffixes were rejected). Anyway,
just to settle this fruitless discussion I'll add a sentence
there.

Jan