EmbDev.net

Forum: ARM programming with GCC/GNU tools how come linker cant detect blown stack?


Author: jtarb (Guest)
Posted on:

Rate this post
0 useful
not useful
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

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
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

Author: jtarb (Guest)
Posted on:

Rate this post
0 useful
not useful
> 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.

Author: Mh Tay (lpc2103)
Posted on:

Rate this post
0 useful
not useful
Ummm... No always predictable...
=> Recursive function calls
=> Nested interrupt service routine
Regards

Author: Stefan (Guest)
Posted on:

Rate this post
0 useful
not useful
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

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
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

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.