This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86: fix disassembly of 16-bit fixed size mem ops
- From: "Jan Beulich" <jbeulich at novell dot com>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: <binutils at sourceware dot org>
- Date: Mon, 04 Dec 2006 08:40:30 +0000
- Subject: Re: [PATCH] x86: fix disassembly of 16-bit fixed size mem ops
- References: <45701CF8.76E4.0078.0@novell.com> <20061201143409.GA27698@lucon.org> <45704E4F.76E4.0078.0@novell.com> <20061201145033.GA27865@lucon.org> <4570677A.76E4.0078.0@novell.com> <20061201165512.GA6473@lucon.org>
>> 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.
Jan