How to identify maximum stack size?

UNIX for Advanced & Expert Users
1

Hi All,

I have set max stack size as 4KB for my thread, but it always using very less.
So I like to know what is the maximum stack size is used by my thread.
I tried with gcc -fstack-usage command line option, but its not supported by mips.
Kindly suggest me the way to find the max stack size.

I can't use GDB for my application.

I am using below compiler

sde-gcc -v
Thread model: mipssde
gcc version 3.4.4 mipssde-6.06.01-20070420
2

man getrusage ("getrusage") should do it

3

It is not possible to get the max stack usage because it varies...even the RSS value is a sum of text data and stack segments and due to the dynamic nature of the stack it could fluctuate between 0 - 4Kb.

4

Dear shamrock thanks for the reply.
My requirement is to analyze the stack size of each function at compile time.
I am not expecting 100% of stack usage, at least we can find static information.

5

if it's self-contained, i.e. doesn't call external library functions, then the amount of space it takes on the stack will be closely related to the total size of its local variables.

If it calls external functions, how much total stack it needs is going to be hard to guess at compile time.

6

So is there is any command or compiler option to find the local variable of nested function calls.
Is there is possible to get these information using (readelf or objdump command)? I have tried but i can't.

7

Think about what "nested function call" means. The compiler is not omniscient. Does the compiler know how many times this is going to recurse?

int recur(int num)
{
      if(num>0) recur(num-1);
      return(0);
}

Feed it 1, it consumes 1 stack frame, feed it 2, it consumes 2 stack frames, and on, and on. There's no static total. There's not even a maximum.

Or how about this code:

int something(void)
{
        external_library_function();
}

The compiler won't know the run-time stack usage of functions it didn't even compile.

What you're asking about is something you need to consider in your algorithm design, or monitor at runtime with a debugger, not something the compiler can fix for you.