From mboxrd@z Thu Jan 1 00:00:00 1970 From: jmk@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-pxbcqfxvdughrbdsciwflzqmpz" Message-Id: <20020124033243.B78CB199E4@mail.cse.psu.edu> Date: Wed, 23 Jan 2002 22:32:41 -0500 Topicbox-Message-UUID: 43533610-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-pxbcqfxvdughrbdsciwflzqmpz Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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. --upas-pxbcqfxvdughrbdsciwflzqmpz Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Wed Jan 23 22:15:36 EST 2002 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Wed Jan 23 22:15:35 EST 2002 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.20.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 7168519A67; Wed, 23 Jan 2002 22:15:10 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by mail.cse.psu.edu (CSE Mail Server) with SMTP id AF43D19A63 for <9fans@cse.psu.edu>; Wed, 23 Jan 2002 22:14:57 -0500 (EST) Received: (qmail 499447 invoked from network); 23 Jan 2002 20:14:57 -0700 Received: from snaresland.acl.lanl.gov (128.165.147.113) by acl.lanl.gov with SMTP; 23 Jan 2002 20:14:57 -0700 Received: (qmail 14138 invoked by uid 3499); 23 Jan 2002 20:14:56 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 Jan 2002 20:14:56 -0700 From: Ronald G Minnich X-X-Sender: To: <9fans@cse.psu.edu> Subject: Re: [9fans] calculating the gdt pointer in 32 bit (protected) mode In-Reply-To: <20020124022401.879EE199E4@mail.cse.psu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 23 Jan 2002 20:14:56 -0700 (MST) 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 --upas-pxbcqfxvdughrbdsciwflzqmpz--