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

[Robert Millan <rmh@aybabtu.com>]

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."