Re: how much stack space can I use
Michael Meissner (meissner@cygnus.com)
Sun, 24 Oct 1999 17:19:46 -0400
On Sun, Oct 24, 1999 at 07:45:38PM +0200, Gerard Roudier wrote:
>
>
> On Sun, 24 Oct 1999, Michael Meissner wrote:
>
> > On Sun, 24 Oct 1999, Keith Owens wrote:
> >
> > > On Sat, 23 Oct 1999 17:36:12 +0200,
> > > Manfred Spraul <manfreds@colorfullife.com> wrote:
> > > >How much stack space can I use without causing a stack overflow? None of
> > > >these functions are recursive, and they don't call any subfunctions
> > > >which need more than a few bytes stack space.
> > >
> > > Anybody looking at stack usage might find this script useful, it can
> > > also be found in ftp://ftp.ocs.com.au/pub/kernel.stack.gz. It taks a
> > > while to run, mainly because objdump --disassemble of everything takes
> > > a while. Some interesting results from 2.2.23 :-
> > >
> > > 7c4 ncr53c8xx_detect
> >
> > You should view any such numbers as approximations, since it only counts the
> > stack size as allocated in the function entry. On the x86, as functions are
> > called, arguments are pushed on the stack (and the return address) and then
> > popped off some time later, so that actual stack size varies by a few words
> > depending on where you are at any point in time.
> >
> > Also note, real old compilers would sometimes delay popping off the stack, and
> > you could have a tight loop that does a call, and accumulates extra words on
> > the stack until the loop exists. I believe this was fixed some time ago, but I
> > haven't kept as much track of the x86 code generation these days.
>
> Thanks for your explanations.
>
> By the way, it seems you replied to my response to the initial posting
> and but just quoted zero lines from it. ;-)
Yes, I didn't pick up on the thread until I saw your response, but since what I
had to say was against the original poster, I just edited the lines (but kept
the references line).
> In fact, I just wanted to say that the information reported about
> ncr53c8xx_detect consuming too much stack was relevant and that I knew of
> that since this feature :) has been introduced in the driver. As I wrote,
> the fix that consists in moving the sym driver init code to ncr is in my
> todo list since months. Btw, an initialisation code that eats too much
> stack is not that dangerous. It is quite different situation for code that
> can be called at any time from the kernel and especially under interrupt.
It has come up occasionally to add a switch to the compiler to tell what the
stack size of the function is (some ports have machine dependent switches that
write the information to stderr), but as I recall the last time it came up, the
problem of calls to alloca, use of the variable sized structure feature, and
machines like the x86/68k that implement push instructions caused us to back
off from doing it.
--
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com phone: 978-486-9304 fax: 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/