Static Analysis for RTEMS

[Joel Sherrill]

On 03/26/2015 04:23 AM, abd el-hamed Amer wrote:
> Dear Dr. Joel sherrill & All,
>
> I have chosen static analysis of stack usage for RTEMS, and I working 
> now on my proposal. can you advice me about the latest work on this 
> topic and which parts see it's important to focus in?
>
This is an idea that came about from a question in an RTEMS class I
taught recently. How do I have confidence on what I configure for
my thread/task stack size?

Our only answer at this point in time is that you use the stack usage
reporter in RTEMS and see how much you have been using. That is
accurate but only informative if you know the scenario that was
used is worst case.

The idea behind this project is that we want to predict the stack usage.
That involves the generation and integration of two pieces of information:

+ gcc has -fstack-usage argument and generates information. See the
gcc manual for more details on this.

But the gcc information is **per function** so that is only a piece of the
puzzle. Somehow you have to figure out the call tree and compute the
total usage based on those calls.

I put a reference to cflow and a simple script that shows how this can be
done in the open project write up.

All the information is there and there are very simple proof of concept
demonstrations out there. But solving this for RTEMS is at least an order
of magnitude more complex. You need visibility into an entire program
which is composed of source from at least the application source,
RTEMS source, and newlib source. There could be additional libraries.
Somehow you need the per function usage on each. That needs to be
gathered during the packages compilation and probably put in a
single installed file that can be referenced later.

Assuming you have all the information on the individual methods, then
you have to determine the program flow. cflow is a program which can
generate this information. I have also seen discussions of doing this
based on analysis of program executables. Using an object dump, this
could be done I think pretty easily and limit the scope. However this
is done, you end up with a program call tree.

After you figure out how to get the information of stack usage per
method and call flow, you will need a tool to integrate this and
combine the information. Summing up the usage. My assumption is
that at least this would be a Python program [1] and be in rtems-tools.git.
If you end up with other code it would likely go here also.

I am assuming that the usage would be for the user to ask for
the usage for a particular method. Then the analysis would do the
magic.

As a broad disclaimer, I know the pieces of information you need.
Using gcc for the function method information is almost a 100%
given. But the flow analysis and user interface is up for discussion.
There is likely more out there I didn't find in my limited research.

NOTE: If the flow analysis includes indirect calls, I am not sure how
to compute down that path. It may end up on first cut with a
marker and a warning that the call includes an indirect call and
that is not included.

[1] Requirement to be in Python and integrate with rtems-tools.

>
> Best Regards,
> Abd elhamid

--joel