On 13/01/12 22:41, Crazy Casta wrote: > 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.
True enough - my suggestion was that it could give ideas (and possibly code) for getting the call graphs. Combined with listing files generated by the compiler and interpreting the function prologues to get the frame size, this might be enough to estimate maximum stack size. It's just an idea, nothing more. > - 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
