Re: pic18f4455 - call graph

On Thu, Jun 9, 2011 at 1:22 PM, Walter Banks <[email protected]> wrote:
> I wrote the MPC (MPLAB) call tree code. =A0The compiler does tail call
> optimization and is part of the stack analysis. =A0Interrupts and functio=
n
> pointers are accounted for.

I found no stack analysis in mcc18 v3.37.01. I found in MPLAB IDE 8.63
a box for stack analysis report, but it just gives error for unknown
option -sa. I tried some code and got no warning about too deep stack.

Anyway, it is good it does tail call optimization.

>> From a call tree you could see the possibility for stack
>> overflow, but it may not be real because a function may
>> not always execute every call contained in it.
>
> Wrong assumption. If every call is not reached at some time then
> it is dead code and will drop out of the application call tree.

I think you missed the point. A call can be conditional on a parameter
or global variable. Even if static analysis shows a deep call tree, it
can be by design that in runtime the function takes the deep call only
when there is enough stack.

> Recursive calls that cannot be resolved by tail end recursion will
> not be found in non hosted embedded systems.

What do you mean by this? Why not?

> Walter Banks
> Byte Craft limited

Marko

> Marko Kohtala wrote:
>
>> MPLAB C compiler records call tree, but I don't remember if the
>> compiler does tail call optimization requiring some analysis to
>> determine if stack is really used or if there is just a goto to next
>> function. Assembly is more difficult because it does not enforce
>> functions and therefore it requires some more analysis to find nested
>> calls. From a call tree you could see the possibility for stack
>> overflow, but it may not be real because a function may not always
>> execute every call contained in it. Think about recursive calls. You
>> need to have room for interrupts and they may not always be enabled
>> and not always use the same amount of stack. And then are the programs
>> that use dynamic calls through function pointers so it is hard to know
>> which function is being called.
>>
>> It would be a fun utility to write. If there are no dynamic calls, it
>> might work by analyzing the binary for basic blocks. For every block
>> that is a target of a call it would find all reachable blocks until a
>> return or loop with no return. It could build the tree from the calls
>> in those basic blocks. It could use as the start of the tree the reset
>> address and interrupt vectors.