This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]