Date:	Sun, 1 Aug 1999 11:31:42 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
cc:	djgpp AT delorie DOT com
Subject:	Re: Fixed stack size?
In-Reply-To:	<7nepgn$34o$2@news.luth.se>
Message-ID:	<Pine.SUN.3.91.990801113121.20304M-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

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.

- Raw text -