how to find the stack size used by a function

By looking at the machine code generated by the compiler.

Homework / study question?

For a more detailed response, give more details of the processor, compiler and runtime environment.

--

Tauno Voipio
tauno voipio (at) iki fi

In which language on what compiler for what device?

using a debugger, break at the

oops

Using a debugger, step through the function and watch the SP.

Hi,

I want to write a program in C using gcc compiler on red hat linux machine.

Regards, Noor

Paul Burke wrote:

If you're going to run the code under Red Hat Linux in a PC, the embedded newsgroup is probably not the correct place for a question.

For a program run in a Linux system, the stack size is the problem of the compiler and the operating system. If you have not done anything silly (like a huge automatic array), the system takes care of the stacks.

--

Tauno Voipio
tauno voipio (at) iki fi

Perhaps it's on a PC-104 stack inside a set-top box?

At any rate, I would either look at the generated assembly and estimate the stack size or I would use gdb to watch the stack pointer.

I can't speak for gcc, but many compilers reserve the maximum possible stack space at the start of any function, so it's pretty easy to tell what's going to happen by examining the entrails. Just compile to assembly and take a look.

In a _really_ embedded system you fill the stack area with some known pattern (zeros, or text 'stack stack stack' or hex 0xF00D or 0xDEAD or

0xDEAF or 0xD00F or on a 36-bit machine 0xFAB4BDEAD -- you get the idea). Then you go back later and you look for the biggest bite that was taken out of the stack.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

If it's standard Red Hat Linux, the stack size gleaned from the code tells the count of linear addresses currently needed from the total address space of the current process.

The virtual memory system uses real memory in page-sized chunks as needed, so it's pretty useless to calculate the stack usage. IIRC, the initial stack reservation for a process is two pages (8192 bytes), and it is expanded at runtime as needed.

An embedded system without backing store is a different story, but it does not run plain Red Hat Linux.

--

Tauno Voipio
tauno voipio (at) iki fi

I was actually bitten by this recently. The commercial RTOS just looked at the stack pointer when you called its functions and detected overflow that way, but that's nearly useless. So in the past someone had put a known value at the top of all the stacks, and then tested if that value had been overwritten. But this was also very deficient because you can overflow the stack without touching that one value at the top.

So I changed this to fill the stack area with a pattern, and then counted down from the top to see the maximum stack usage of all the tasks and ISRs. It caught some potential problems right away, so I was feeling pretty smug about this (smugness goeth before a fall). But it turned out there was one third party function that put a 26KB variable on the stack. So when calling it with about 16KB of stack free, it completely overshot the top of the stack. This wasn't noticed by my scheme which reported that a sizeable 16KB was still unused.

-- Darin Johnson

That's why in one of the projects I am working on now, I am getting into the habit of converting any automatic variable larger than a few tens of bytes to file global scope.

It makes assessing stack & memory needs much easier. It is better to get a linker error due to overflow in one memory segment, than to have a stack overflow at run time.

Regardless how you determine the stack usage for a specific function, the result depends on the compiler version and to compilation switches used (optimisation, debug etc.), thus, even if the result is correct for specific test settings, it might not be correct for the actual production version.

In C, look carefully on local variables declared within a local block like

if (condition1) { int i, j, k ; some_operations_on_i_j_and_k }

since the variables i, j, k might be allocated on the stack only if condition1 is true.

Paul

Or, if you want to keep scope down to the function, declare it as static.

Steve

That would not do exactly the same in my case. (I did not provide all the details.)

You are right in that declaring an automatic variable as static will remove it from the stack, but I want also to control were these variables are located.

The memory map for this project has several discontinuous memory segments with different properties. Different access times , some areas are cpu-internal flash memory, some are external (slower) flash memory, some are RAM, some are battery-protected non-volatile RAM, etc.

I can define the size and locations of these memory areas with a linker configuration file, and force a particular variable to be in one of these segments using "#pragma" directives. The problem is that this pragmas work only with global objects, not with static objects with function scope.

So for example, all the transmit and receive data buffers for a communications subsystem (that could be private to the tx/rx ISRs and com handling functions,) are now global variables and each one of them is preceded by a #pragma that locates all of them in the same segment.

If in the future I run into performance problems, I can relocate all the buffers from external RAM (were they are today,) to faster internal RAM by changing one line in the linker config file. This would be impossible if the buffers were function static, (which would have been the logical way to define them without these environmental oddities.)

Roberto Waltman

[ Please reply to the group, return address is invalid ]

Heh.

Scope control is such fiun, doncha think?

Steve