Re: Glitches in gas/objdump handling of i386 STR, SLDT, SMSW instructions

[Zack Weinberg <zack at codesourcery dot com>]

On Mon, Nov 12, 2001 at 09:36:26PM +0100, Maciej W. Rozycki wrote:
> 
>  Have you checked the prefixes are got right in the 16-bit mode, either?

Well, I don't have a convenient 286 to try the code on, but given

        .code16
        str     %bx
        str     %ebx
        nop
        strw    %bx
        strl    %ebx
        nop
        str     (%bx)
        strw    (%bx)

objdump -mi8086 produces:

   0:   66 0f 00 cb             strl   %ebx
   4:   66 0f 00 cb             strl   %ebx
   8:   90                      nop    
   9:   0f 00 cb                str    %bx
   c:   66 0f 00 cb             strl   %ebx
  10:   90                      nop    
  11:   0f 00 0f                str    (%bx)
  14:   0f 00 0f                str    (%bx)

which is correct except that the bare 'str %bx' at offset 9 will be
misinterpreted if fed back into the assembler.

> > and that produces an identical object file when fed back into the
> > assembler.  So we're now almost correct.  The remaining problem is
> > that suffix_always mode will disassemble 0f 00 0b as strl (%ebx),
> > which is wrong and will be rejected by the assembler when fed back in.
> 
>  Do you need a suffix in the disassembly at all?

The semantics of the instruction coupled with the backward
compatibility hack are sufficiently weird that I'm starting to think
the disassembler should _always_ suffix this instruction.

	unsuffixed	equivalent

	str %bx		strl %ebx
	str %ebx	strl %ebx
	str (%ebx)	strw (%ebx)

None of these three get a 66 prefix.

Ugh, and then there's Intel notation to deal with; there's currently
no way to get 66 0f 00 cb out of the assembler in 32-bit Intel mode.

> > Also I wonder if any of the other [sl]<seg> instructions need the same
> > treatment.
> 
>  [sl]ldt has exactly the same semantics as do moves from/to segment
> registers.  [sl]msw has, too, even though it doesn't operate on
> selectors. 

*nod* Fortunately, we don't have a backward compatibility problem with
those instructions.  Therefore, the simple 

{"sldt",    1, 0x0f00, 1, Cpu286, wlq_Suf|Modrm,         { WordReg, 0, 0} },
{"sldt",    1, 0x0f00, 1, Cpu286, w_Suf|Modrm|IgnoreSize,{ ShortMem, 0, 0} },

should suffice for them - once I figure out how to get the
disassembler to cooperate.

zw