Re: PATCH: Fix i386 disassembler with index == 0x4 in SIB (Re: objdump bug-report)

[Alan Modra <amodra at bigpond dot net dot au>]

On Thu, Jan 13, 2005 at 09:08:49AM -0800, H. J. Lu wrote:
> On Thu, Jan 13, 2005 at 02:14:40PM +1030, Alan Modra wrote:
> > On Wed, Jan 12, 2005 at 11:10:52AM -0800, H. J. Lu wrote:
> > > > 	.byte	0x8B, 0x04, 0x63	# effect is: movl (%ebx), %eax	
> > [snip]
> > > >  8048081:	8b 04 63             	mov    (%ebx,2),%eax
> > 
> > I don't agree that this is a problem.  In fact, I think that this
> > disassembly is more accurate than "mov (%ebx),%eax".  Note that gas
> > accepts "mov (%ebx,2),%eax" giving
> > Warning: scale factor of 2 without an index register
> 
> But it generates "8b 03", not "8b 04 63".

Sure.  That's an optimization, just like mov %es,%ax is assembled
without the operand size prefix as if the programmer had written
mov %es,%eax.  I'm quite happy with the assembler optimizing a little
where it can.  :)

> > Yes, I agree that the effect of executing these byte sequences is the
> > same as "mov (%ebx),%eax", but that's beside the point.  For example,
> > plenty of x86 instructions execute as a nop, but that doesn't mean they
> > should all be disassembled as "nop".  The disassembler ought to reflect
> > the machine encoding as closely as possible, and in this case that means
> > printing the ignored scale factor.
> > 
> > I think this change should be reverted.

> 
> IA-32 instruction reference manual says when INDEX == 0x4, scaled index
> is "[none]". Displaying "(%ebx,2)" is simply wrong here.

The IA-32 instruction reference manual specifies both instruction
operation and instruction encoding.  There isn't a one to one mapping
between encoding and operation on IA-32, sometimes multiple encodings
are available for a particular operation.

And that's where I have a philosophical disagreement with Allan Cruse.
I believe the disassembler should reflect the encoding as much as
possible, while he seems to believe the disassembler should reflect
operation.  The trouble with that argument is that taken to its logical
conclusion we should disassemble
  0x89,0xf6 as "nop"
  0x8d,0x76,0x00 as "nop"
  0x8d,0x74,0x26,0x00 as "nop"
and so on for all of the zillion different "nop" encodings.  Indeed,
that might help some people.  We've had the occasional bug report that
gas wasn't aligning with nops!  But people use the disassembler for more
that just teaching, where instruction operation might be the primary
concern.  I'd guess that programmers casually debugging programs are
most interested in instruction operation too, but more advanced analysis
might focus on execution speed and instruction scheduling where
different encodings do sometimes behave differently.  There's also the
possibility of subtle cpu bugs that only show up in certain machine
encodings.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre