[PATCH] D20830: Fix branch relaxation in 16-bit mode.

[James Y Knight via llvm-commits]

jyknight accepted this revision.
jyknight added a reviewer: jyknight.
jyknight added a comment.
This revision is now accepted and ready to land.

In http://reviews.llvm.org/D20830#462108, @niravd wrote:

> In http://reviews.llvm.org/D20830#461914, @craig.topper wrote:
>
> > Are there cases where 16-bit mode may need a full 32-bit offset that we need to support here? Or would that wrap the segment boundary for 16-bit mode and be illegal?
>
>
> Yes, since EIP calculation is always truncated to 16-bit so we can safely truncate our offset in the instruction and none of the exception checks make use of the top 16-bits of the 32-bit new EIP so it should always be okay to do the 16-bit truncated calculation in lieu of the 32-bit one.


I don't think that's actually true. TTBOMK, EIP is actually only truncated to 16-bits for the jump/call instructions with 16-bit operands, so EIP can get above 64k either via linear program execution, or via executing a jump with a 32bit operand.

In Real mode, typically the segment limit is 64k anyways, so you can't actually access more. But, it is possible to set the limit higher via trickery (search "Unreal mode"), and reportedly this does work to let you access more code -- until you hit an interrupt, which will only save/restore the lower 16bits of EIP (oops).

In Protected mode, you can also change the default address/data operand sizes back to 16-bit, where that last part about interrupts isn't a problem anymore.

All that aside, -m16 / .code16 really is intended to imply that you're planning to fit your code/data within 64k. That is a sane meaning, and also what binutils has always done as well.

Theoretically, one might want to have a compiler mode which emits 16-bit instructions, but with 32-bit relocations/fixups. But that'd be pretty esoteric, and neither binutils nor llvm really have a goal of supporting all the crazy things you might ever possibly be able to do in x86 16-bit modes.

So, this change seems good to me.


http://reviews.llvm.org/D20830