Overview

To implement this feature, HCL OneTest™ Embedded uses two mixed technologies:
  • Static analysis that computes the call graph of the application (Example: all the calls between functions are analyzed and computed as a graph),
  • Dynamic analysis that provides the stack size of each functions when executing them.
This information is used to provide an estimation of the worst stack size. This estimation is accurate under the following conditions:
  • All the functions of the application should have been executed at least once in order to have the stack size for each of them.
  • Your application should not have recursive calls, because the number of loops in the recursive calls being unpredictable, it is impossible to compute the stack size.
  • If your application used libraries (Example: call functions for which we have not the source code), you should provide an additional file that gives an estimation of the stack size for each of them. These estimations do not need to be precise, but should be an upper bound of the exact stack size.
  • If your compiler optimizes the Stack Size, you might have different Stack Sizes for the same function. In this case, the Worst Stack Size is computed with the maximum value found in the different runs.
  • If your application is multi-threaded, you can provide the list of entry points so that HCL OneTest™ Embedded can calculate the worst total stack size and compare it to the maximum memory stack available on your target to produce a pass/failed verdict.

For the Worst Stack, HCL OneTest™ Embedded provides a brand-new interactive HTML-based report. This report identifies if one or more of these conditions are not met.

How Worst Stack Size Works
When an application node is executed, the source code is instrumented by the Instrumentor (attolcc4 for C language) that produces a static file with the .tsf extension that contains information on the functions (this file is common with Control Coupling feature). The resulting source code is then compiled, linked and executed and the Control Coupling feature outputs a dynamic file with the extension .tzf.
These 2 types of files are used in input of the report generator that produces a report in HTML format (and optionally the raw data can be generated in a Json file). A template is provided for this generator. You can provide your own template to modify the report. An addition file could be provided to this report generator in order to specify the stack size of the external functions.
Note:
To visualize your report in Eclipse, if you are using the default browser option, be sure that JavaScript is enabled. Otherwise, you can choose another browser that is compatible with your version of JavaScript by changing it in Window> Preferences> General > Web Browser.