Date:	Thu, 11 Jul 1996 14:30:16 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	j DOT aldrich6 AT genie DOT com
Cc:	a DOT appleyard AT fs2 DOT mt DOT umist DOT ac DOT uk, djgpp AT delorie DOT com,
	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject:	Re: What if I run out of store
In-Reply-To:	<199607110154.AA100990054@relay1.geis.com>
Message-Id:	<Pine.SUN.3.91.960711142145.7359D-100000@is>
Mime-Version:	1.0

On Thu, 11 Jul 1996 j DOT aldrich6 AT genie DOT com wrote:

> 1)  If you set _stklen within your program, then you can just examine
>     that, but is _stklen defined if you didn't do it yourself?

_stklen is defined by crt0.s, even if you don't do that in your program.

> 2)  Also, what about STUBEDIT being used to increase (or decrease)
>     the runtime stack?  This would, for obvious reasons, invalidate
>     the internal value of _stklen, unless it is changed by the program 
>     itself at runtime.

The larger value of these two is used.  See crt0.s for details.

> 3)  What about running the program under a debugger like gdb, which has
>     its own runtime stack?

The debuggee inherits the maximum stack of the debugger, yes (see the FAQ,
section 15.9), unless you debug a stubbed .exe file (currently only
possible with fsdb), in which case the stack size is still determined by
the debuggee. 

> Also, if you read the section in the FAQ which deals with increasing stack
> space,
> it implies that unless the size of the stack that thestub allocates for your
> program is >= the size you specified in _stklen, the stub's stack is discarded
> and a completely new stack is allocated, essentially wasting the space for
> the stub's.

Hmmm... that FAQ fragment goes back to v1.x, and as far as I can see now 
in the v2 startup code it's probably incorrect.  It seems that now the 
two values are first compared, the larger one determined, and then used 
to sbrk the space for the stack.  Charles, is that correct?  If so, I 
should correct the FAQ.

- Raw text -