Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode

Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode

[Russ Cox]

The lgdt function in l.s is known to work
in 32-bit mode.  Have you tried that?
Once you get started, each mmu runs on
its own gdt.  See 9/pc/mmu.c.

Russ

Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode

[Ronald G Minnich]

On Wed, 23 Jan 2002, Russ Cox wrote:

> The lgdt function in l.s is known to work
> in 32-bit mode.  Have you tried that?

Are you sure? I've done lgdt instructions in 32-bit mode before and the
l.s version has a few problems:

The tgdtptr is not right. For 16-bit mode, a gdtptr looks like this:

struct gdtp {unsigned short size; unsigned long base} (PACKED);

for 32-bit mode the base becomes a 16:32 type thing, and since 48-bit
things are not well handled in C, most people code it as:

struct gdtp {unsigned short size; unsigned long long base} (PACKED);

The tgdtptr in l.s only reservers a short for the size and a long for the
base, and that's too small for 32-bit mode.
(see two kernel monte or LOBOS)

Anyway, we're tracing the lgdt in l.s with an american arium ICE and it
blows the processor out of the water every time we hit it. What I'm
doing now is going back and figuring how I ever got this working with
LOBOS.

I hate Pentiums :-)

ron

Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode

[jmk]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

No.

The x86 instruction set definition says the operand is a pointer to
6 bytes of data in memory that contains the base address (a LINEAR address)
and the limit (size of table in bytes) of the GDT. The only difference
between being called from real or protected mode is that in real mode only
24 bits of the 32- bit address are loaded, the high-order byte of the base
address in the GDT is loaded with 0.


[-- Attachment #2: Type: message/rfc822, Size: 2739 bytes --]

From: Ronald G Minnich <rminnich@lanl.gov>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode
Date: Wed, 23 Jan 2002 20:14:56 -0700 (MST)
Message-ID: <Pine.LNX.4.33.0201232010570.14130-100000@snaresland.acl.lanl.gov>

On Wed, 23 Jan 2002, Russ Cox wrote:

> The lgdt function in l.s is known to work
> in 32-bit mode.  Have you tried that?

Are you sure? I've done lgdt instructions in 32-bit mode before and the
l.s version has a few problems:

The tgdtptr is not right. For 16-bit mode, a gdtptr looks like this:

struct gdtp {unsigned short size; unsigned long base} (PACKED);

for 32-bit mode the base becomes a 16:32 type thing, and since 48-bit
things are not well handled in C, most people code it as:

struct gdtp {unsigned short size; unsigned long long base} (PACKED);

The tgdtptr in l.s only reservers a short for the size and a long for the
base, and that's too small for 32-bit mode.
(see two kernel monte or LOBOS)

Anyway, we're tracing the lgdt in l.s with an american arium ICE and it
blows the processor out of the water every time we hit it. What I'm
doing now is going back and figuring how I ever got this working with
LOBOS.

I hate Pentiums :-)

ron

Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode

[andrey mirtchovski]

the instruction is:

	BYTE		$0x0f
	BYTE 	$0x01
	BYTE 	$0x16
	LONG	$tgdptr-KZERO(SB)

when traced it resembles:

	MOVL	([ESI]+($tgdptr-KZERO(SB))), GDTR

(the 0x16 tells it that the address if offset from ESI)

if instead one assembles:

	MOVL	$tgdptr-KZERO(SB), GDTR

(as it is written in the comments above the original
instruction) then the third byte becomes 0x15 and
it starts thinking that the pointer is actually a 32 bit
displacement, which is even less correct (i think)..

i'm going to start debugging using the proven trial-
error method and will see which takes me to the
correct GDT pointer..

am i correct in my assumption that i am unable to
modify the ESI register? otherwise i'd be tempted
to put the pointer value in ESI and execute the
instruction with 0 displacement from ESI..

i could of course be terribly wrong in everything i've
done so far...

andrey

Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode

[jmk]

[-- Attachment #1: Type: text/plain, Size: 38 bytes --]

perhaps
	LONG	$tgdtptr-KZERO(SB)
?

[-- Attachment #2: Type: message/rfc822, Size: 1593 bytes --]

From: andrey mirtchovski <andrey@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode
Date: Wed, 23 Jan 2002 17:21:02 -0700
Message-ID: <20020124002127.1192719A02@mail.cse.psu.edu>

unfortunately that still crashes the machine..

the code as i have written it is in 'mode32bit' (l.s):

//.... mode32bit entry and some testing outputs
	 BYTE	$0x0f
	 BYTE	$0x01
	 BYTE	$0x16
	 LONG	$tgdtptr(SB)
// ..... real mode32bit continues...

anything obvious i'm missing?

andrey

Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode

[andrey mirtchovski]

unfortunately that still crashes the machine..

the code as i have written it is in 'mode32bit' (l.s):

//.... mode32bit entry and some testing outputs
	 BYTE	$0x0f
	 BYTE	$0x01
	 BYTE	$0x16
	 LONG	$tgdtptr(SB)
// ..... real mode32bit continues...

anything obvious i'm missing?

andrey

Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode

[Russ Cox]

It's pretty much what it says.
$tgdtptr(SB) is a constant evaluated
for us by the loader as though it were
a function.

The byte sequence here:

	 BYTE	$0x0f
	 BYTE	$0x01
	 BYTE	$0x16
	 WORD	$tgdtptr(SB)

assembles to "LGDT $tgdtptr".
It's a word-sized instruction, though.
If you're already in 32-bit mode, you
need to use

	 BYTE	$0x0f
	 BYTE	$0x01
	 BYTE	$0x16
	 LONG	$tgdtptr(SB)

so that the immediate data is the right size.

Russ

[9fans] calculating the gdt pointer in 32 bit (protected) mode

[andrey mirtchovski]

hello,

i'm trying to understand how the gdt pointer is calculated in
/sys/src/boot/pc/l.s ..  the exercise includes calculating this
pointer when already in 32 bit mode and i'm kind of lost at this
point...

here's the relevant code snippet:

/*
 * pointer to initial gdt
 */ TEXT tgdtptr(SB),$0

        WORD $(3*8)
        LONG $tgdt-KZERO(SB) /*
 * goto protected mode
 */ /* MOVL tgdtptr(SB),GDTR /**/
         BYTE $0x0f
         BYTE $0x01
         BYTE $0x16
         WORD $tgdtptr(SB)
        MOVL CR0,AX
        ORL $1,AX
        MOVL AX,CR0



using MOVL tgdtptr(SB),GDTR to calculate the gdt pointer when already
in protected mode crashes the machine, although not immediately...


thanx, andrey