[PATCH] x86: fix disassembly of 16-bit fixed size mem ops

H. J. Lu hjl@lucon.org
Mon Dec 4 15:56:00 GMT 2006


On Mon, Dec 04, 2006 at 08:40:30AM +0000, Jan Beulich wrote:
> >> The Intel disassembly version actually exposes a disassembler bug; I'll
> >> commit it with a broken expectation for now until I get to fix this. The
> >> problem is that on calls and jumps in Intel mode there's no defined way
> >> to express an operand size override with the opcode or operand,
> >> hence it gets a data16 prefix disassembled, but that obviously leads
> >> to the immediate being treated as 32 bits wide when the actual opcode
> >> then is being dealt with in the next step. I'm not sure how to actually
> >> address this - use a suffix here, too? Use a 'small' operand modifier
> >> like Borland's TASM does?
> >
> >How does Microsoft ASM handle it?  Can you open a bug report with
> >a testcase? I'd like to track it.
> 
> They don't seem to permit this at all (after all, this is pretty useless - at
> least I can't imagine where it would make sense).
> However, a quick test also shows that you *have* to use e.g. pushfd in
> 32-bit mode (pushf assembles as 16-bit op, and there's no pushfw).
> This all seems pretty ugly, so I'm not sure we want to be *this* close to
> MASM.

What does nasm do? If it isn't supported by those Intel mode
assemblers, we can just pick something which works for gas. If gas
doesn't support it either, we can pick anything as long as it won't
assemble.


H.J.



More information about the Binutils mailing list