Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port)

[Robert Millan <rmh@aybabtu.com>]

On Mon, Jun 22, 2009 at 05:44:43PM -0400, Pavel Roskin wrote:
> On Mon, 2009-06-22 at 23:32 +0200, Robert Millan wrote:
> > On Mon, Jun 22, 2009 at 10:52:13PM +0200, Robert Millan wrote:
> > > I don't think it's possible to use relative addresses
> > > with this particular instruction.
> > 
> > Uhm sorry, this was silly.  Of course you can use addresses relative to a
> > segment in lgdt, but this doesn't change the fact that GAS always gives
> > you absolute ones.
> > 
> > Also, I'm not sure if it's possible to use a 16-bit field in this instruction,
> > it could be that the field is always 32-bit, even if it's relative to a
> > segment.  This dump is from the i386-pc kernel.img:
> > 
> >     836f:       2e 67 66 0f 01 15 68    addr32 lgdtl %cs:0x8368
> >     8376:       83 00 00 
> > 
> > a little-endian 0x00008368 is seen here, indicating the field is 32-bit.
> 
> But if I omit ADDR32, I get:
> 
> 0000016e <real_to_prot>:
>  16e:   fa                      cli    
>  16f:   2e 66 0f 01 16 68 01    lgdtl  %cs:0x168
>  176:   0f 20 c0                mov    %cr0,%eax
> 
> The address is 16-bit.

If I omit ADDR32 on i386-pc, I get:

    836f:       2e 66 0f 01 16 68 83    lgdtl  %cs:-0x7c98

"-0x7c98" being the signed version of 0x8368, which is also 16-bit.  What is
really odd is that you got 0x168 which is an offset to 0x8200, when in fact
%cs is 0, so I don't think your binary would work (did you test it?).

Btw my binutils version is 2.18.0.20080103.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."