binutils, why default stack size this low ?

binutils, why default stack size this low ?

[Pascal Obry]

Hello,

We have seen that the default stack size for the binutils on Windows has been
reduced to 0x200000 (2 mb). Why this have been set so low. We have seen
regressions on some (not so big) Ada code because of this change.

The change has been done on 2001-06-05:

<<
2001-06-05  Danny Smith  <danny_r_smith_2001@yahoo.co.nz>

	* emultempl/pe.em (init): Reduce default stack reserve to 0x200000.
>>

Previous version was 0x2000000 (32 mb). Note that we are talking about stack
reserve, nothing is commited as Windows does commit on use.

Pascal Obry.

Re: binutils, why default stack size this low ?

[DJ Delorie]

Larger reserves limited the number of threads you could start.  The
MSVC compiler had a much smaller reserve than Cygwin before the patch.

Re: binutils, why default stack size this low ?

[Danny Smith]

 --- Pascal Obry <obry@ACT-Europe.FR> wrote: > 
> > Larger reserves limited the number of threads you could start.  The
> > MSVC compiler had a much smaller reserve than Cygwin before the patch.
> 
> Right, but this has the bad consequence to break some non-threaded
> programs. It was always possible to change the default stack size on the
> command line. 

It still is.

Of course this is also true for non-threaded programs, but
> I
> think that most of the programs around us do not use threads.
> 
> Even on the Ada world, where tasking is part of the language, we have
> many
> programs that do not use tasks (threads), and those who do does not have
> enough tasks to break the limit (which is around 35 if my memory 
> is right).
> 
> Pascal Obry. 

Well, what should the default be? I chose 2 MB because:

1) Default of native compiler is 1 MB. Inspection of apps built by other
W32 comilers indicates they have similar or smaller default stack reserve. 
1 MB, however, is not sufficient to bootstrap GCC. 2 MB is.

2) Threads (and fibers).  Although CreateThread allows user to set stack
size, if size is smaller than default, the new thread uses the same size as
the calling thread.  With fibers, it is not possible to specify stack
reserve; the size of the calling thread is always used. Apps that use
fibers ("lightweight threads") can often (try to) create a 100 or more.


The larger the stack reserve, the more likely that illegitimate 
__stdcall/__cdecl fixups will go undetected.  One way that this can happen
is to compile C code with -mrtd.  Library functions that are not marked as
__cdecl in headers will also be treated as stdcall.  Sooner or later the
stack will overflow. Better sooner than later.

Danny

http://my.yahoo.com.au - My Yahoo!
- It's My Yahoo! Get your own!

binutils, why default stack size this low ?

[Pascal Obry]

> Larger reserves limited the number of threads you could start.  The
> MSVC compiler had a much smaller reserve than Cygwin before the patch.

Right, but this has the bad consequence to break some non-threaded
programs. It was always possible to change the default stack size on the
command line. Of course this is also true for non-threaded programs, but I
think that most of the programs around us do not use threads.

Even on the Ada world, where tasking is part of the language, we have many
programs that do not use tasks (threads), and those who do does not have
enough tasks to break the limit (which is around 35 if my memory 
is right).

Pascal Obry.