Re: pic18f4455 - call graph

I wrote the MPC (MPLAB) call tree code.  The compiler does tail call
optimization and is part of the stack analysis.  Interrupts and function
pointers are accounted for.

> 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.

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

Walter Banks
Byte Craft limited


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.