This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: x86-64-branch-3 test case
On 13.12.2019 17:09, H.J. Lu wrote:
> On Fri, Dec 13, 2019 at 1:39 AM Jan Beulich <jbeulich@suse.com> 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