This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86/Intel: fix indirect far jmp/call with operand size specified


>>> "H.J. Lu" <hjl.tools@gmail.com> 25.02.08 15:33 >>>
>On Mon, Feb 25, 2008 at 10:53:40AM +0000, Jan Beulich wrote:
>> >>> "H.J. Lu" <hjl.tools@gmail.com> 22.02.08 16:48 >>>
>> >On Fri, Feb 22, 2008 at 03:33:42PM +0000, Jan Beulich wrote:
>> >> >> -jmp, 1, 0xff, 0x4, 1, Cpu64, Modrm|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64, { Reg64
>> >|Qword|Unspecified|BaseIndex|Disp8|Disp32|Disp32S|JumpAbsolute }
>> > >> +jmp, 1, 0xff, 0x4, 1, Cpu64, Modrm|No_bSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64, { Reg16|Reg64
>> >|Word|Qword|Unspecified|BaseIndex|Disp8|Disp32|Disp32S|JumpAbsolute }
>> >> >
>> >> >This is wrong. 64bit jump/call only support 64bit reg/mem.
>> >> 
>> >> I just made jmp match call. And I'm pretty sure it's actually valid (despite
>> >> being pointless); I think I even tried it out once. It's just like 16-bit
>> >> push/pop is encodable, even though it makes little sense.
>> >> 
>> >
>> >My Intel64 SDM r26 says that only "jump/call r/m64" is supported in
>> >64bit. Does AMD say differently?
>> 
>> Yes, AMD does not only say different, it also permits executing a 16-bit
>> jump here (and I'm pretty sure earlier Intel EM64T CPUs also allowed this).
>> Since encoding this is as useful (or useless) as encoding a 16-bit jump in
>> 32-bit mode, I'd like to ask you to revert the respective change you did.
>
>I didn't remove 16-bit jump in 32-bit mode. Why do you want 16-bit
>jump in 64-bit mode when both Intel and AMD say it is invalid?

AMD does *not* say it's invalid, as I stated above.

Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]