On Sun, Jun 21, 2009 at 09:22:41PM -0400, Pavel Roskin wrote: > On Mon, 2009-06-22 at 00:53 +0200, Robert Millan wrote: > > In this line of code in real_to_prot(): > > > > DATA32 ADDR32 lgdt %cs:gdtdesc > > > > GAS generates an absolute address for `gdtdesc' (not relative to segment), > > and so for the code to work %cs must be zero. In current usage of > > real_to_prot(), %cs is always zero because we jump to 0x0:0x82xx early on. > > > > However, in other situations this is not possible. On i386-qemu, before > > moving to i386 mode the code we're running is in the 0xf0000-0x100000 > > range, which is inaccessible from segment 0. > > But gdtdesc should be next to the code we are running, since startup.S > includes realmode.S where gdtdesc is defined, so they compile into one > object file. > > 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. > As for the APPLE_CC issue, I guess the Apple compiler doesn't understand > the segment prefix at that position. The right fix would be to use > ".byte" statements to create the same bytecode instead of introducing a > different behavior to work around a compiler limitation. > > Then I guess the Apple compiler won't accepted %ds: either, so if we > want to use %ds, we should omit it. Yes, this should work. -- 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
