Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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