This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Addressing Layout in 1.3.x


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]