comp.lang.ada
 help / color / mirror / Atom feed
From: "Jeff Creem" <jeff@thecreems.com>
Subject: Re: stack frame too large
Date: 2000/11/11
Date: 2000-11-11T00:00:00+00:00	[thread overview]
Message-ID: <t0re33sh15sr52@corp.supernews.com> (raw)
In-Reply-To: ihiP5.13$el3.60726@news.pacbell.net

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....






  reply	other threads:[~2000-11-11  0:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-10  0:00 stack frame too large wayne lydecker
2000-11-11  0:00 ` David Starner
2000-11-11  0:00 ` Marc A. Criley
2000-11-11  0:00   ` Wayne Lydecker
2000-11-11  0:00     ` Jeff Creem [this message]
2000-11-12  0:00     ` Marc A. Criley
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox