how come linker cant detect blown stack?
Guest
#1171246
Hello,
I was just wondering... :) why the linker can't detect when there are
too large of stack variables... given that it knows the target's memory
limits from the link script. This is what im talking about:
void myfunction(){
char big[ 9999999 ];
...
}
-jt
jtarb wrote: > Hello, > > I was just wondering... :) why the linker can't detect when there are > too large of stack variables... given that it knows the target's memory > limits from the link script. This is what im talking about: > > void myfunction(){ > char big[ 9999999 ]; > ... > } > > > -jt Because the stack is blown at runtime. The linker has no visibility of local variables. Its job is to resolve external symbol addresses and locate static data. Conversely, the compiler, has no visibility of the memory environment. It is true that the stack will always be blown with that somewhat perverse example, so it could be detected in principle, but it would require bothe the compiler and the linker to coordinate. Moreover there are many more undetectable and likely stack overflow possibilities that it is not worth making the linker more complex by testing for the 'obvious' situations. Clifford
Guest
#1171248
> Because the stack is blown at runtime. The linker has no visibility of > local variables. Its job is to resolve external symbol addresses and > locate static data. Conversely, the compiler, has no visibility of the > memory environment. > I see. So basically because the 'stack' is really just a counter in register sp... its a loose idea the tools dont have much control over. It would be nice to know though, the largest nested stack frame sum. Seems like you could pull the information out of .lst files, if you just had .c code in your project and you werent messing with the stack pointer. Ummm... No always predictable... => Recursive function calls => Nested interrupt service routine Regards
Guest
#1171250
jtarb wrote: > I see. So basically because the 'stack' is really just a counter in > register sp... its a loose idea the tools dont have much control over. > It would be nice to know though, the largest nested stack frame sum. Not a academic approach, but some pragmatic ones in order to do such a profiling: Clamp the stack with two additional variables which you put on the stack. The distance between the addresses of these variables is a rough estimation of the used stack between the two definitions. Or get the sp register in each function entry or exit (easier) and compute the the distance to the stack base/top address (see startup code for global symbols for these). Some macros and inline assembler will do the job. Stefan MH Tay wrote: > Ummm... No always predictable... > => Recursive function calls > => Nested interrupt service routine > Regards I am not sure who or what that comment was directed at, but I assume it was my statement; "there are many more undetectable and likely stack overflow possibilities"? I should qulaify that: It is possible to detect 'worse case' stack depth by extensive static analysis. In trivial applications this could be done manually. In complex applications it would require tool support. I am not aware of any compiler that provides such support. In practice, the 'worse case' conditions are never met. For example say that a level of recursion were determined by some sensor input that was of known limited range, if the value was held in an unsigned int for example, a static analysis tool would assume 'worse case' that the value could take 2^32 possible values - it might predict a stack overflow that cannot occur in the real world. Moreover, the problem is much more complex even than that. In most simple systems, the different stacks are used for the interrupt and exception handler contexts, and if an RTOS is used, each task has a stack. The stacks for each task are allocated at runtime from either the heap or from static memory. Clifford ReplyPlease log in before posting. |