operand size override (push 0xd) about keystone HOT 9 CLOSED

is this for x86 32bit?

from keystone.

Oh yes sorry I forgot to mention that.

from keystone.

how do Nasm, Xed, or any assemblers handle this case?

i tried with some, but none accepts "push word 0x0d" or "push dword 0x0d", or can distinguish the differences.

from keystone.

With XED there is no textual input so the user has to specify whether a word or dword was intended. OA assumes a dword per default (as does XEDParse) so I'd say assuming a dword is the correct behavior.

As for handling pushing a word I don't really know to be honest. This website mentions using pushw and pushd to explicitly tell the assembler what to emit.

from keystone.

nasm and gnu as in intel mode output 6A 0D for push 0x0d. nasm supports push word 0x0d (which outputs 66 6A 0D), gnu as supports push word ptr 0x0d in intel mode (which also outputs 66 6A 0D). I have no idea how to convince gnu as in AT&T mode to output these opcodes (pushw $13 yields 66 FF 35 03 00 00 00, which is push word [dword 3]).

from keystone.

this is fixed now

$ kstool x32 "push 0xd"
push 0xd = [ 6a 0d ]

$ kstool x32 "push word 0xd"
push word 0xd = [ 66 6a 0d ]

from keystone.

Great!

from keystone.

from keystone.

Yes I will look at all of them as soon as possible. I added some more tests
to XEDParse that currently fail for various reasons. I believe they pass
Keystone.
On Tue, 14 Jun 2016 at 19:17, Nguyen Anh Quynh [email protected]
wrote:

can you confirm all the other issues you reported? most of them are fixed
now.

—
You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub
#10 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACWCmbjWgjW4YQHpTgoma7jVk8YvOO4Dks5qLuI5gaJpZM4ISiQq
.

from keystone.