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."
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
