OSDev.org

Posted: **Fri Nov 20, 2009 10:50 pm**

Hi all,

A coding case arose that I needed to far jump using a 64-bit offset. Checking the Intel instruction reference manual, I gladly found the far jump:

Code: Select all

REX.W + FF/5 JMP m16:64

which I interpreted as an indirect jump, guided by the 10 bytes region pointed by m16:64, containing a 2-byte %cs selector and an 8-byte offset.

But unfortunately, I found this under the far jumps section in the AMD instruction reference:

Control is transferred to the target CS:rIP. In this case, the target offset can only be a 16 or 32 bit value, depending on operand-size, and is zero-extended to 64 bits.

It may help to state that for testing purposes, I used two "REX.W far jump"s with 64-bit offsets. One in early kernel bootup code and one in the SMP trampoline. Code worked nicely on CVS Bochs and on my Intel Core2 hardware, but failed on qemu.

I've been able to work around the 64-bit offset need; I'm wondering though, is this a real inconsistency, or a problem in my interpretations?

Thank you!

Posted: **Sat Nov 21, 2009 2:30 am**

It may help to state that for testing purposes, I used two "REX.W far jump"s with 64-bit offsets. One in early kernel bootup code and one in the SMP trampoline. Code
worked nicely on CVS Bochs and on my Intel Core2 hardware, but failed on qemu.

Bochs implementation is according to Intel latest docs and verified vs Intel hardware.

I've been able to work around the 64-bit offset need; I'm wondering though, is this a real inconsistency, or a problem in my interpretations?

I don't have AMD hardware to verify against but I think it is real inconsistency.
Or at least it was real inconsistency before - AMD and Intel converging to the same definition of x86-64 by adding "small stuff" like this into never CPU to minimize divergence.
But when I started with testing of x86-64 stuff in Bochs I was hard time to find any test case of JMP FAR or CALL FAR in 64-bit mode at all in any commercial OS.
It looks like people worked it around and never used these instructions ...

Stanislav

Posted: **Sat Nov 21, 2009 3:20 am**

Hi,

I note from the AMD 64 bit System Programming Manual section 2.5.10 that the Jmp Far (absolute) instruction is invalid. Looking around, it seems that the instruction you found reference to is, annoyingly, sign extended on AMD64. Also:

Branches to 64-Bit Offsets: Because immediate values are generally limited to 32 bits, the only way
a full 64-bit absolute RIP can be specified in 64-bit mode is with an indirect branch. For this reason,
direct forms of far branches are eliminated from the instruction set in 64-bit mode.

The first workaround that springs to mind is to push the desired address on to the stack and then perform a 64 bit RET. Whether this works or not, I haven't tried in practice. If not (if you don't mind some hackishness!), you could also push current stack locations and then use IRETQ.

Cheers,
Adam

OSDev.org

Indirect x64 far jump offsets, AMD and Intel inconsitency?

Indirect x64 far jump offsets, AMD and Intel inconsitency?

Re: Indirect x64 far jump offsets, AMD and Intel inconsitency?

Re: Indirect x64 far jump offsets, AMD and Intel inconsitency?