Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Date:	Thu, 31 May 2001 17:58:43 -0400
From:	Christopher Faylor <cgf AT redhat DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Addressing Layout in 1.3.x
Message-ID:	<20010531175843.B26180@redhat.com>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20010531090143 DOT 0263bf78 AT ks DOT teknowledge DOT com> <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20010531090143 DOT 0263bf78 AT ks DOT teknowledge DOT com> <20010531150106 DOT O23914 AT redhat DOT com> <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20010531132733 DOT 03877550 AT ks DOT teknowledge DOT com>
Mime-Version:	1.0
User-Agent:	Mutt/1.3.11i
In-Reply-To:	<5.1.0.14.2.20010531132733.03877550@ks.teknowledge.com>; from rrschulz@cris.com on Thu, May 31, 2001 at 02:08:21PM -0700

On Thu, May 31, 2001 at 02:08:21PM -0700, Randall R Schulz wrote:
>Chris,
>
>Let me try asking it this way...
>
>Preliminaries:
>
>According to "Inside Microsoft(tm) Windows(r) 2000 3rd ed." when Windows 
>2000 is operating in the 2GB max mode (there's a boot-time 3GB option that 
>alters these values), user mode application code, globals, per-thread 
>stacks and DLLs load at virtual addresses from 0x00000000 to 0x7fffffff. 
>The kernel and executive, the hardware abstraction layer (HAL) and the boot 
>drivers use virtual addresses from 0x80000000 to 0xC0000000; process page 
>tables go from 0xC0000000 to 0xC0800000 and the system cache and the paged 
>and nonpaged pools extend the rest of the way, to 0xffffffff.
>
>A corollary of the kind of "bit-convenient" (and at least partially VM 
>hardware-dictated) virtual address allocation used by Windows (and lots of 
>other operating systems) is that if I know I'm manipulating, say, pointers 
>to process page table entries, than I can use the two most significant bits 
>of those pointers for my own purposes as long as I set them both to 1 
>before dereferencing them to actually access the page table entry. 
>(Ignoring any access restrictions that may be placed on those virtual 
>addresses, of course).
>
>An interpreter like XSB uses tag bits to make the values it manipulates 
>self-identifying as to their data types. Because some of the data types it 
>manipulates in this way are actually machine-level pointers, it has to 
>restore the proper, fixed values for those bits before dereferencing the 
>resulting / equivalent pointer.
>
>
>Now, my question(s):
>
>a) Does Cygwin impose additional structure to address allocation within the 
>application / global / thread stack / DLL area, and if so b) might those 
>assignments / alignments have changed in the 1.1.x -> 1.3.x transition?
>
>
>Does that clarify my question?

Slightly, but the answer is still "I don't know".  We're using the Win32
API.  We don't interact with the OS in any way other than through the
OS, with the exception being that we do manipulate the stack in strange
ways for signals.  We've done this since 1.1.4 or so.

So, none of what you have mentioned above should have any bearing on
normal cygwin operation in any version of Cygwin from B16.0 on.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

- Raw text -