Stack Usage Analysis need to know deeps of recursion, all possible calls when indirect calls is used etc.
That all has to be described in suc-file according to IAR rules.
Do anybody have experience of using Stack Usage Analysis of IAR for projects where FreeRTOS is used?
If this is a IAR feature, you should probably reach out to them for better response. You can use uxTaskGetStackHighWaterMark API for determining stack space used by a task.
I have already talked with IAR.
Their Stack Usage Analysis is very good.
But it must know all possible indirection calls, max depth of recursions, etc.
If Linker doesn’t know this information – developer has to add this information in suc-file. There is specific syntax of it.
IAR can help with writing this file. But IAR don’t have information about possible indirection calls, max depth of recursions,… of FreeRTOS source code.
IAR will not investigate FreeRTOS source code!
It is difficult for me to investigate whole(!!!) FreeRTOS source code too.
Maybe did anybody have experience preparing this suc-file for FreeRTOS sources code?
uxTaskGetStackHighWaterMark is good instrument too. And I use it too.
But it informs about problem when it is already happened.
IAR Stack Usage Analysis calculates max possible depth of Stack during Linker stage. And Linker error is generated when the selected Stack size is smaller than max possible depth of Stack.
uxTaskGetStackHighWaterMark can miss very rare problems. IAR Stack Usage Analysis is safer for detection these rare problems.
I have not done this, so I cannot provide a definitive answer. Is it possible to use Clang/LLVM to generate callgraph - GitHub - bernardnongpoh/CallGraph: A CallGraph Generation LLVM Pass for C and C++ program.
Thank you very much!
I will try it!
I think that it would be good idea for FreeRTOS developers to prepare suc-file.
IAR is very popular and powerful development tool. Many tests inform that code, which is generated by IAR Compiler, is faster than other.
Clang/LLVM may be add additional information.
But Stack Usage Analysis of IAR need to know ALL possible indirection calls and MAX depth recursion (if it is present). It has also to know with function reload LR register (and some other) for calling root function.
Stack Usage Analysis is very powerful tool. It saved me a lot of times from stack crashing in projects without complex Middlware (like FreeRTOS)
When Stack Usage Analysis tells me that size of stack is sufficient – I am 99,999% sure that there will be no stack overflow, and the size of stack isn’t more than necessary.
I can’t be sure that is so for project where FreeRTOS is used. I can be sure that stack overflow wasn’t happened during development and testing stage since the last stack overflow occasion.
reliable stack trace/ control flow analysis is not an easy task. If you look at the ARM Cortex family of processors, for example, the compiler may generate code that does not look like anything related to the source code. For example, a tail recursive optimization may eliminate a function call altogether, then code unfolding may duplicate the code several times to support cache lookahead performance gains, and sometimes code is inlined.
To make things even more interesting, some ports switch stacks for interrupts, so at a breakpoint, you may be looking at the isr stack which may look fine whereas the interrupted task may have overflown without your analyzer seeing it.
I currently work with the Lauterbach tool suite which is one of the very best debuggers available, but even there, it is at times impossible to follow the chain back.
Given that FreeRTOS is an open source project, I encourage you to contribute that feature yourself. Great learning experience, and you will undesrand that there is a LOT of work to do even for a single port, let alone for all or even most popular targets. There probably is a reason why IAR has not tackled that itself yet.
I fully agree with you.
Of course, FreeRTOS is open-source project. But learning FreeRTOS architecture will not be done by only users of it. Mayb somebody who whant to be part of developer team…
I hope, that this chat is read by somebody form FreeRTOS developer team. Only they can make suc-file – description file for Stack Usage Analysis of IAR. Anybody other practically can’t do it.
If this file is present, it will increase use FreeRTOS in projects where IAR tool is used. And these projects will be very stable from stack overflow.
This chat is constantly monitored by FreeRTOS developers (in fact, @aggarg is one).
I believe your assessment is wrong. Why should only FreeRTOS developers be able to generate files whose format is proprietary to and defined by IAR? I would argue that only IAR would be able to do that.
Also, again, FreeRTOS is 100% open source; thus, anybody willing to dig deep enough into the subject matter and in possession of the .suc file spec should be able to do it. Or am I missing anything here?
Now I think that your assessment is wrong.
IAR develops tools. Syntax of suc-file consists from few directives. Everybody knows specification of suc-file who uses IAR tool. There is no problem to describe known information in this file. The single problem is to know information which has to be described in it!
I asked IAR to help. I have active Support and update Agreement with them. They are ready to consult me how describe known information. But they are not want to investigate FreeRTOS or others Third Paty Middleware. This is not their business…
If FreeRTOS developer team is interest to give possibility analytical forbiddance of stack overflow during Link stage – it can do it for IAR tool (may be for others too if they have similar functionality) when prepares and uploads template of suc-file (or other for others tools) where stack usage is described, which can’t be define analytically without knowing of architecture of Middleware.
No point in arguing. The cards are on the table - we probably agree that there is a significant amount of work involved in providing the support you ask for. Whoever is willing and/or able to put down the money (or do it for nil which is also an option for Open Source Software) is welcome to do it, but the decision is not a technical one but a project management decision. I am a technical person (and I know why I want it to remain that way 
), so let the keepers of the money fight it out. I guess I would be happy either way.
Yes, I agree with you. Every work has value. Free charge works also costs!
If there is interest to do, what I propose FreeRTOS developer team - It will be done.
If it is not interesting - stack overflow will be fixed only after that was detected by FreeRTOS hooks.
Analytical detection of stack overflow in project with FreeRTOS is possible. I think not only IAR has similar tools. I use IAR… But the interest has to be for it.