T1.stack

Static stack analysis

based on the executable

Static stack analysis with T1.stack

Based on the binary (the ELF file), T1.stack performs a static code analysis: the binary is disassembled, function calls are extracted and the call tree is reconstructed. At the same time the stack consumption for each function is determined. The call tree and the stack consumption per function are combined into the comprehensive and powerful T1.stack view.

Indirect function calls

For any static code analysis there are limitations with respect to resolving indirect function calls. Such calls typically use function pointers and it is essential to know all call-targets (functions) which can possibly be called at run-time. T1.stack allows to complete any gaps in the static analysis through annotation. Three kinds of annotation are supported: manual annotation, import of generated annotation files and annotation through T1.flex measurements. Simply measuring call-targets is unique and a highlight of T1.stack. Such measurements can also be used to cross-check and verify annotations from other sources.

Unresolved indirect function call:

Resolved indirect function call by dynamic T1.flex measurement:

T1.stack offers the advantage of detailed analysis. It detects not only of the amount of used stack but also how and why it is used. Deep understanding of stack consumption allows successful optimization of stack usage and detection of unintended or purposeless use of the stack. Using less stack often helps to improve runtime performance. When using a high level language it is not possible to pre- dict the stack usage from even a detailed knowledge of the C source code. With auto-generated code, the problem is even worse. Using T1.stack, stack consumption can be continually tracked so that the effects of coding and compiler flags can be monitored and understood.

The accurate and detailed analysis of total stack usage combined with validation allows stacks to be reliably dimensioned with T1.stack and thus avoids the waste of allocating unnecessary memory. What's more: stack-overflows can be avoided.

Key benefits include:

  • Static analysis based on the binary file
  • 3rd party code can be analyzed without the source code
  • Compiler effects (e.g. optimizations) are also taken into account
  • Measurement assisted resolving of indirect function calls (function pointers)
  • Extreme fast analysis (e.g. a 150MB ELF file of an engine management ECU could be analyzed in less than two minutes on a regular PC)
  • Call tree offers additional insights into the software structure
  • Built-In source code- and disassembly-viewer (disassembly-viewer supported for NXP/ STM e200z0-z4, z6, z7 and Infineon TC1.6.X)

Supported processors

Silicon/IP
Vendor		 Core Architecture Controller Examples
Infineon TC1.6.X, TC1.8 TC2xx, TC3xx, TC4x
NXP/STM e200z0-z4, z6, z7 MPC57xx, MPC56xx, MPC55xx, SPC58xx, SPC57xx, SPC56xx, etc.
ARM ARMv7-R: Cortex-R4, Cortex-R4F, Cortex-R5F TMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x, TMS570LC43x, etc.
ARM ARMv8-R: Cortex-R52 ST SR6 Stellar, NXP S32S
ARM ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 * Infineon Traveo II, LPC17xx, STM32F4xx, Atmel SAM V71, etc.
Renesas RH850 G3K/G3KH/G3M/G3MH/G4MH RH850/C1x, RH850/F1x, RH850/P1x, RH850/E2x, etc.
Intel x86 64-bit Intel Atom Denverton, etc.

(*) Cortex-M4 adds DSP and FPU to Cortex-M3. Cortex-M7 further adds a 64-bit bus and double precision FPU. T1 uses the shared sub-set of the instruction sets.