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


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?

H.J.


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