EmbDev.net

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


how come linker cant detect blown stack?
von jtarb (Guest)

Rate this post
• ▲ 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

Report post Edit Move Thread sperren Anmeldepflicht aktivieren Anpinnen Delete topic Thread mit anderem zusammenführen Quote selected text Reply Reply with quote
Re: how come linker cant detect blown stack?
von Clifford S. (clifford)

Rate this post
• ▲ 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

Report post Edit Delete Quote selected text Reply Reply with quote
Re: how come linker cant detect blown stack?
von jtarb (Guest)

Rate this post
• ▲ 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.

Report post Edit Delete Quote selected text Reply Reply with quote
Re: how come linker cant detect blown stack?
von Mh T. (lpc2103)

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

Report post Edit Delete Quote selected text Reply Reply with quote
Re: how come linker cant detect blown stack?
von Stefan (Guest)

Rate this post
• ▲ 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

Report post Edit Delete Quote selected text Reply Reply with quote
Re: how come linker cant detect blown stack?
von Clifford S. (clifford)

Rate this post
• ▲ 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

Report post Edit Delete Quote selected text Reply Reply with quote
Watch this topic | Disable multi-page view
Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.