Date: Sun, 1 Aug 1999 11:31:42 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Martin Str|mberg cc: djgpp AT delorie DOT com Subject: Re: Fixed stack size? In-Reply-To: <7nepgn$34o$2@news.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 25 Jul 1999, Martin Str|mberg wrote: > Hmm. I wonder how Linux handles this? I have no idea, but remember that Linux doesn't have to live with DPMI limitations, the most severe of which is that the DPMI client doesn't have any control on the location (i.e. the logical address) of a memory block that it requests from the DPMI server. > : If you are willing to have the stack be part of the same segment as .data, > : bss and the heap, then you cannot place it ``as high as possible'', > : since that would mean your initial address space will be too large (it > : has to map in the high addresses), and you lose some of the memory > : protection. > > Welllll... If the pages is unmapped shouldn't the DPMI server realise > that a pointer that is outside the allocated amount of memory should > result in SIGSEGV? I think you are confusing ``unmapped'' with ``paged in''. A page whose address is inside the segment limits is ``mapped'', but not ``paged in'' until you touch some address inside that page. When you do touch that address, a page fault indeed happens, but it is handled by the DPMI host which brings the page into memory and returns to the client. If this were not how it works, you would have been hit by a SIGSEGV each time you accessed another 4KB part of a large malloc'ed block.