Where to find the stack info used in keil c?

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.

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.