This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86/Intel: fix indirect far jmp/call with operand size specified
On Mon, Feb 25, 2008 at 02:48:55PM +0000, Jan Beulich wrote:
> >>> "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.
>
Hi Michael,
Can you check if AMD64 allows "jmp/call r/m16" in 64bit, which is
invalid for Intel64?
Thanks.
H.J.