Re: [Nasm-devel] [nasm:master] disasm: Fix for disassembly of BOUND

[H. P. A. <hp...@zy...>]

On 11/03/15 12:12, nasm-bot for Mark Scott wrote:
> Commit-ID:  db6ecf9b76a25c465887946fe70e74b3dcdce234
> Gitweb:     http://repo.or.cz/w/nasm.git?a=commitdiff;h=db6ecf9b76a25c465887946fe70e74b3dcdce234
> Author:     Mark Scott <na...@ms...>
> AuthorDate: Tue, 3 Nov 2015 23:09:05 +0300
> Committer:  Cyrill Gorcunov <gor...@gm...>
> CommitDate: Tue, 3 Nov 2015 23:09:05 +0300
> 
> disasm: Fix for disassembly of BOUND
> 
> The opcode for BOUND, 62h, has a different meaning in long mode - it is the
> prefix for EVEX instructions. ndisasm did not take this into account and always
> tried to disassemble 62h back to an EVEX instruction.
> 
> Attached patch only permits EVEX disassembly if bitness is 64.
> In 16/32 bit mode 62h will be not be a prefix and so disassemble
> to BOUND.
> 
> Signed-off-by: Mark Scott <na...@ms...>
> Signed-off-by: Cyrill Gorcunov <gor...@gm...>
> 

This is wrong, though; EVEX is permitted in 32-bit mode just as VEX is.

The key thing is that bits [7:5] have to be 1 in 32-bit mode.  It is
unclear what happens if these bits are 110 as that depends on if it is
decoded using the modr/m decoder or not.  For VEX prefixes we accept
them as VEX in that case, which may not match the CPU.

The evex_p0 test seems to have been taken out of thin air; I don't think
that is a requirement for EVEX.

So, I believe the logic should in fact be the exactly same logic that we
have for VEX:

            if (segsize == 64 || (data[1] & 0xc0) == 0xc0) {

	-hpa