Re: Really weird things happening in Guile/GDB

[Jim Blandy]

Mikael Djurfeldt <address@hidden> writes:
> > If the value on the FP TOS is correct, but the value stored in memory
> > is not, then I wonder whether that instruction is being assembled
> > correctly.  Can you do an x/8b $pc or whatever and check its bits
> > against the Intel manual?
> 
> The fildll is assembled as 0xdf 6d f8, which seems to be wrong
> according to the instruction manual.  6d refers to %edi instead of
> %ebp which would be assembled as 6e.

Are you looking at the ModR/M chart for 16-bit addressing forms, and
not the 32-bit addressing form chart?  At least in my copy, a ModR/M
byte of 0x6d in an instruction using 32-bit addressing means an
effective address of disp8[EBP] and an opcode extension of /5, which
is `fild'.

(What a horrible instruction set!)

I would play around more with that fildll instruction.  Can you
reproduce its misbehavior in other contexts?  Does it matter what the
value is being loaded?

> However, the same type of error
> (wrong register code) is present in the instructions which load the
> operand onto the stack:
> 
>   movl %eax,-8(%ebp) : 89 45 f8  (should be 89 46 f8)

That one looks correct to me, too.

> BTW, why this difference between the intel manual and GCC/GDB???

It's historical.  The first Unix assemblers for the i386 from AT&T
used a syntax which was more consistent with other Unix assemblers.
AT&T puts the destination on the right; Intel puts it on the left.
Intel chooses operand size based on the registers that appear, and
sometimes based on special qualifiers; AT&T uses suffixes to the
opcode.  It's quite a mess.

You can tell GDB to use Intel-style disassembly if you want, by saying

   (gdb) set disassembly-flavor intel

No joke.