Where to find the stack info used in keil c?

I think keil c should give us a warnning at least. because:
1. it can locate the start address of stack;
2. it can output the call tree( in *.m51);
3. the compiler certainly knows operations of push and pop instructions(except programmer's assemble code).
so, keil c51 can get the deepest(include interrupt routine) stack length and should warn us the risk of stack overflow.
welcome to give advice or comments. thanx!

I think keil c should give us a warnning at least. because:
1. it can locate the start address of stack;
2. it can output the call tree( in *.m51);
3. the compiler certainly knows operations of push and pop instructions(except programmer's assemble code).
so, keil c51 can get the deepest(include interrupt routine) stack length and should warn us the risk of stack overflow.
welcome to give advice or comments. thanx!

I agree. If the compiler/linker could work together to print out a max known stack usage for each branch of the overlay map, I would know the exact amout of bytes I could throw over to my communication buffers.

I think keil c should give us a warnning at least. because:
1. it can locate the start address of stack;
2. it can output the call tree( in *.m51);
3. the compiler certainly knows operations of push and pop instructions(except programmer's assemble code).

AND the "compiler" does NOT know the possibilities of interrupts interrupting interrupts and the number of reentrancies of those reentrant function some of you use.

By the way The compiler does not know diddlysquat in this respect, only the linker does.

I would rather have no answer than an answer that may be wrong.

stack overflow is about the easiest to check, use yout ICE or whatever to fill the stack area with something, run the thing and if all is overwritten you have an overflow. Then find the maximum stack usage of interrupts at all IP priorities and add the most of any at each IP priority. If there is room for that you are safe.

Erik

A dynamic stack fill test assumes you are able to force the execution path down the deepest path of control. There are two problems in doing so: (1) being able to force to that path while the system is running, and (2) even knowing what that path is in the first place.

Note that (2) is exactly the same information the OP requested: an output of the static analysis already done by the linker indicating the the max-depth path down the call tree.

The information doesn't have to be complete to be useful. For instance, if the linker gives me the depth of the main body, plus that of each interrupt function, I can decide for myself what the actual depth it. Sure, the linker doesn't know when the interrupts occur, but that doesn't mean the information is does have is wrong. It just needs a little more analysis. And having the linker provide this information is a lot faster and more reliable than doing it manually.

The occasional bit of generated code or library routine will throw in a PUSH/POP which aren't obvious from inspecting the source. Only the toolchain can really produce the right answer.

I've wanted this feature from every compiler I've ever used. It's particular appropriate for C51, as the tools already do the analysis, and the usual reasons for not providing the information -- recursion and reentrant functions -- are much, much less common than in workstation-style code.