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

[Pavel Roskin <proski@gnu.org>]

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.

Maybe you are trying to use a copy of gdtdesc in the beginning of
memory?  If GRUB serves as BIOS in i386-qemu, I'd rather use the "BIOS"
value in the 0xF000 segment rather than the "RAM".

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.

-- 
Regards,
Pavel Roskin