[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i38
From: |
Robert Millan |
Subject: |
Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port) |
Date: |
Mon, 22 Jun 2009 11:52:52 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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."
- Re: [PATCH] rename kernel.elf to kernel.img (Re: [PATCH] i386-qemu port), (continued)
- [PATCH] swap real_to_prot() and prot_to_real() (Re: [PATCH] i386-qemu port), Robert Millan, 2009/06/21
- Re: [PATCH] i386-qemu port, Robert Millan, 2009/06/21
- [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port), Robert Millan, 2009/06/21
- Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port), Pavel Roskin, 2009/06/21
- Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port),
Robert Millan <=
- Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port), Pavel Roskin, 2009/06/22
- Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port), Robert Millan, 2009/06/22
- Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port), Robert Millan, 2009/06/22
- Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port), Pavel Roskin, 2009/06/22
- Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port), Robert Millan, 2009/06/22
- Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port), Pavel Roskin, 2009/06/22
- Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port), Robert Millan, 2009/06/23
- Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port), Pavel Roskin, 2009/06/22
- Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port), Robert Millan, 2009/06/22
- about Apple compiler (Re: [PATCH] access gdtdesc on segment 0 unconditionally (Re: [PATCH] i386-qemu port)), Robert Millan, 2009/06/22