This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Glitches in gas/objdump handling of i386 STR, SLDT, SMSW instructions
On Mon, Nov 12, 2001 at 12:59:30PM -0800, Zack Weinberg wrote:
> 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
This isn't right. You shouldn't have a prefix here.
> 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.
Assembler error.
> > > 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.
IMO, the first one should.
> > > 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.
Do you want me to run with your patch from here? Not that I want to
butt in if you have your teeth into it, but I know this code well...
Regards, Alan