From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ea99a8822847633f
X-Google-Attributes: gid103376,public
From: "Jeff Creem" <jeff@thecreems.com>
Subject: Re: stack frame too large
Date: 2000/11/11
Message-ID: <t0re33sh15sr52@corp.supernews.com>#1/1
X-Deja-AN: 692503222
References: <3A0C9FB8.9EBC9A7F@pacbell.net> <3A0D4A91.8C219079@earthlink.net>
 <ihiP5.13$el3.60726@news.pacbell.net>
X-Priority: 3
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Complaints-To: newsabuse@supernews.com
Organization: Posted via Supernews, http://www.supernews.com
X-MSMail-Priority: Normal
Newsgroups: comp.lang.ada
Date: 2000-11-11T00:00:00+00:00
List-Id: <comp.lang.ada>

Stuff Deleted
>
> Thanks, that does help.  Why is there a limit on the stack frame size?
> I played with the above example some more last night and found that
> between 1,017 and 1,018 integers (<4Kb) the warning is generated.  I
> was hoping I could throw a compile, link, or run switch to bump up the
> stack frame size.
>
> Another solution to the problem will be to use pointers.  Unfortunately,
> there are many instances of this in our code and none of them are nearly
> as simple as the above example.
>
> Thanks again,
>
> -- Wayne.
>
>

You can easily increase the stack size for your tasks with rep specs
and the mainline program task with unix commands (assuming csh)
limit stacksize  SOMEBIGNUMBER

The limit that GNAT is talking about here is a limit for reliable stack
frame
size error detection. I suspect what is happening here is (and this is a
guess -
a gcc/gnat guru could answer this better), is that the stack checks that
GNAT
emits are done by allocating a non R/W block of memory at the top of the
stack so
that if something spills into it a "interrupt" is cause by the runtime. THe
problem is that
with large single variables it might jump all the way past the "protected"
frame and if no accesses
were done within the protected area no error would be detected. (or
something a little like this).

The other way for a compiler to detect stack size problems is to insert code
that checks the
stack pointer before/after each expansion. This is probably a little slower
and also does
not detect the case when an Ada call to a C routine is done and the C
routine
overflows the stack....