Subject: Re: stack size (was Re[2]: serious bug with CYGNUS GCC b16)
From: [email-masked] ("wiljan")

5 Dec 1996 15:04:35 -0800
Sender: [email-masked]
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Original-To: <[email-masked]>, "Sean McNeil" <[email-masked]>
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Original-Sender: [email-masked]

Hello Sean,

You wrote:
> This explains a question I was getting ready to pose.  Apparantly, gcc
> adds stack probing whenever allocating large (>4k) space on the stack.
> I thought that this would extend the stack.  I guess it does assist in
> doing so by increments of sizecommit, but will not extend past
> sizereserve.  So, I need to set the sizereserve to something nice and
> large.  As mentioned, this is done with the -stack option to ld and can
> be made a default option when linking with gcc.
Do not make it to large. There is another trade of to take when using
threads.
A while ago I run into a problem that I was not able to create more then
125
threads on nt (using gnat304a of course). I had not idea what caused this.
A while later and giving it some thoughts when strugling with the linker
options
I came to the conclusion that for every thread such a piece of memory is
reserved.
Originally Labtek had the stack reserve size on hex 100 0000. Note that the
maximum userspace is 2 0000 0000 hex. This means that when having stacks
reserved for this size there is only room for 128 stacks.
I changed the stack reserve size to a much lower amount.
After that I was able to create much more threads (tasks) then before.

Wiljan

-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".