Just a few things to add:
- First, the doxygen code isn't going to understand msp430 assembly
(unless they have some special plugin for it, which is unlikely), so I'm
not quite sure where you're going with that.
- Second, all the cases are simple enough to detect, so I would suggest
checking them and giving an error message describing failure (not sure if
you already had this in mind or not). For the case of recursive functions,
it would be a cycle in the graph. For interrupts it would be an eint or
equivalent instruction in the interrupt (the interrupt flag is disabled
upon interruption; to use nested interrupts you clear w/e bit caused your
current interrupt, to prevent recursion and do an eint).
- There's another case that would probably be the most problematic which
is function pointers. Some of the functions (like uprintf) are fairly
commonly used (as opposed to recursion on an embedded system). I would
guess that the special case of statically passed function pointers would
not be terribly difficult to somehow include, but ofc I haven't tried ;)
- It would be nice to take into account dint/eint, i.e. don't report
non-int+int stack space for sections of code that have interrupts disabled
(only report non-int stack space)
- One other thing that you forgot to mention here is that you're
ignoring looping. It might be slightly better to flag as an error any loop
during which the stack space grows. This would in general be fairly
strange, but ofc not impossible, even in C.
On Fri, Jan 13, 2012 at 3:44 AM, David Brown <da...@westcontrol.com> wrote:
> On 12/01/2012 13:49, Wayne Uroda wrote:
> > Hello,
> >
> > I am interested in starting an open source tool for msp430
> > development, specifically to perform static, whole elf analysis to
> > investigate stack usage. Such a tool can identify maximum stack depth
> > of each function and also find the maximum stack usage of an entire
> > executable.
> >
> > I have a tool which I wrote and use personally but it is limited and
> > specifically coded for the custom link setup I use for my company's
> > products, so I wish to start from scratch.
> >
> > Before I begin I just wanted to check that I wasn't reinventing the
> > wheel. How I have done it in the past was by parsing the output of
> > the disassembler, building a graph of function calls and then
> > analysing each function for instructions which modify the stack.
> > Would I be better off trying to insert this functionality into the
> > compiler/linker/disassembler itself? I have a feeling this would be a
> > lot more complicated.
> >
> > I plan on using C++. Any comments are welcome.
> >
> > Thanks, - Wayne Uroda
> >
>
> I don't know if it will be of much use to you, but it is possible you
> can look at how doxygen generates call graphs and see if you can re-use
> code or ideas.
>
> mvh.,
>
> David
>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
