Encoder mishandles 16-bit address truncation behavior about zydis HOT 2 CLOSED

These examples indicate that it's not just the encoder that's mishandling 16-bit address truncation, but the formatter as well.

While displacements can always be treated as signed in x86, address truncation is unsigned. Also - and this is the part that Zydis doesn't appear to handle correctly - the 67h prefix overrides not just address calculation width but address truncation width as well.

As a result:

• in 32-bit mode, decoding 67 00 3e 00 ff as add byte ptr ds:[0x0000FF00],bh is correct - in this case, the 67h prefix overrides truncation width from 32-bit down to 16-bit, and the resulting memory access goes to ds:[0x0000FF00], not ds:[0xFFFFFF00]. As a result, re-encoding 00 3d 00 ff ff ff into 67 00 3e 00 ff is not correct, but it would have been correct to re-encode 00 3d 00 ff 00 00 into 67 00 3e 00 ff.
• in 16-bit mode, decoding 67 3a 05 00 1e 57 1a as cmp al, byte ptr ds:[0x1E00] is NOT correct! The 67h prefix will, in this case, override address truncation width from 16-bit to 32-bit, so the memory access will go to address ds:[0x1a571e00], not ds:[0x1e00]. As such, the correct decoding is cmp al, byte ptr ds:[0x1a571e00] - which is what e.g. XED outputs. (Attempting to access address ds:[0x1a571e00] in 16-bit mode will normally cause a #GP, due to the data segment size normally being 64K in 16-bit mode, however it is perfectly possible to set up a big 32-bit data segment for unreal-mode or 16-bit protected-mode, in which case such an instruction will execute just fine in 16-bit mode.)

from zydis.

@tremalrik I've addressed this already in #472 :)

Separate PR will soon address rest of the issues.

from zydis.