From: W DOT Derks AT nl DOT cis DOT philips DOT com ("wiljan") Subject: Re: stack size (was Re[2]: serious bug with CYGNUS GCC b16) 5 Dec 1996 15:04:35 -0800 Sender: daemon AT cygnus DOT com Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199612052049.VAA04194.cygnus.gnu-win32@nl.cis.philips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Original-To: , "Sean McNeil" X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Original-Sender: owner-gnu-win32 AT cygnus DOT com 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 "gnu-win32-request AT cygnus DOT com" with one line of text: "help".