gnupic: Thread: pic18f4455 - call graph

Hello,
I am wondering if there is any functionality in gputils to see the call graph/call tree?
Given the limitation of the hardware stack being 31 levels deep, I want to ensurethat none of my call's are nested that deep.
Any thoughts, please?
ThanksSiva 		 	   		  

I do not remember seeing one. But I thought about it a while back.

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.

Marko

On Wed, Jun 8, 2011 at 4:26 PM, Sivaram Gowkanapalli
####@####.#### wrote:
>
> Hello,
> I am wondering if there is any functionality in gputils to see the call graph/call tree?
> Given the limitation of the hardware stack being 31 levels deep, I want to ensurethat none of my call's are nested that deep.
> Any thoughts, please?
> ThanksSiva

> 
> Hello,
> I am wondering if there is any functionality in gputils to see the call
> graph/call tree?
> Given the limitation of the hardware stack being 31 levels deep, I want to
> ensurethat none of my call's are nested that deep.
> Any thoughts, please?
> ThanksSiva 		 	   		  
> 

Hi, try Doxygen. I am using it to generate call graphs without problems. You just need Graphviz package to convert images. Both work on Windows as well.

Vaclav

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.

On Thu, Jun 9, 2011 at 1:22 PM, Walter Banks ####@####.#### wrote:
> 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.

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.

Hello Vaclav,

Just checked out Doxygen. There does not seem to be anything
to convert microchip asm to doxygen C/C++ code. Are you aware
of anything that can do that?

BTW, Why do you mention Graphviz? To transform the images 
produced by doxygen into a stack listing?

ThanksSiva

> Date: Thu, 9 Jun 2011 09:17:25 +0200
> To: ####@####.####
> From: ####@####.####
> Subject: Re: pic18f4455 - call graph
> 
> 
> > 
> > Hello,
> > I am wondering if there is any functionality in gputils to see the call
> > graph/call tree?
> > Given the limitation of the hardware stack being 31 levels deep, I want to
> > ensurethat none of my call's are nested that deep.
> > Any thoughts, please?
> > ThanksSiva 		 	   		  
> > 
> 
> Hi, try Doxygen. I am using it to generate call graphs without problems. You just need Graphviz package to convert images. Both work on Windows as well.
> 
> Vaclav
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
 		 	   		  

> 
> Hello Vaclav,
> 
> Just checked out Doxygen. There does not seem to be anything
> to convert microchip asm to doxygen C/C++ code. Are you aware
> of anything that can do that?
> 
> BTW, Why do you mention Graphviz? To transform the images 
> produced by doxygen into a stack listing?
> 
> ThanksSiva

Hi Siva,

you wanted call tree for ASM code ? Then I am sorry, Doxygen is for C/C++. I read too fast to notice ASM... I never wrote such advanced code in ASM to have some need to show call tree. Thus I can't help you with it.

If I understood correctly, Doxygen generates images in some vector format. Therefore you need "dot" ( part of Graphviz) to convert images to format for HTML pages.

Vaclav