> PS, about AT&T syntax, Ulrich do you save
> the actual opcode anywhere ?
You don't really want to access the opcode again ;-)
To get this right, you'd need to know at least the code segment
descriptor's 'default' bit and whether an operand size override
(and possibly also address size override) prefix is present ...
> The problem
> is that byte- and word/long- instructions
> have separate opcodes, and as far as I can
> see you lose this infomation when you call
> decode().
The information is certainly present (I am using this very code
in a i386 emulator I've written - if there's enough data to correctly
*emulate* the instruction, there should be enough to display it
correctly ;-)), it's just not as easily accessible as I thought
(always using operand_size was stupid, sorry :-/).
You need to access the sizes of the single operands: op[i].size.
The problem is that for some opcodes it's not clear *which* operand
to use, e.g for 'in' you need to use the size of the source operand
and ignore the one of the destination operand, while for 'out' it's
just the opposite. Then again, there are some opcodes *without*
operands, for which you do need to fall back to the default operand_size.
> I had a look at the objdump code,
> they had in their instruction name table
> separate names for, for instance,
> addb and addw/l (which was called addS,
> where the S was replaced by the correct
> suffix later on).
This is probably the best idea. You could have letters like 'S', 'D', ...
where a 'S' is replaced by the size of the source operand (op[1].size),
while 'D' is replaced by the size of the destination (op[0].size) etc.
(Note that you don't need to have separate addb and addw/l, as the
source operand size will be 1, 2, or 4 respectively, so just addS
should work.)
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
