On Mon, Jun 22, 2009 at 03:39:03PM -0400, Pavel Roskin wrote: > On Mon, 2009-06-22 at 11:52 +0200, Robert Millan wrote: > > > Since %cs is pointing to the code, it should be possible to point it to > > > gdtdesc. They should be nearby. > > > > It is nearby, but the address reference for `gdtdesc' is absolute, NOT > > relative to %cs. Of course, when %cs is 0 that's no problem. But in my > > case I can't set %cs to 0 because my code is above 0x10000. > > I think we can remove ADDR32 from the command. I tried that on i386-pc > and it works in qemu and on real hardware. I don't see any need to use > a 32-bit address in the lgdt command.
This won't build. I don't think it's possible to use relative addresses with this particular instruction. "DATA32 lgdt %cs:gdtdesc" results in: boot_img-boot_i386_qemu_boot.o: In function `real_to_prot': (.text+0x64): relocation truncated to fit: R_386_16 against `.text' What's the problem with removing %cs? It's presence there is bogus. It *seems* to indicate gdtdesc is a segment-relative reference, but in fact it's not, and it just happens to work because %cs was set to 0. Note: "ADDR32 lgdt %cs:gdtdesc" builds, but generates an absolute address too. -- 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
