Weisse Spuren
Surprisingly different, surprisingly effective ./design2013/header-t1-4_web.png


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.

Click on image to enlarge

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:

Click on image to enlarge
stack disassembly
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

Core Controller Examples
InfineonTC1.6.XTC2xx, TC3xx
NXP/STMe200z0-z4, z6, z7MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
NXP/STMe200z2, z4, z7MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
ArmARMv7-R: Cortex-R4, Cortex-R4F, Cortex-R5FTMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x, TMS570LC43x, etc.
ArmARMv8-R: Cortex-R52ST Stellar, NXP S32S
ArmARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 *LPC17xx, STM32F4xx, Atmel SAM V71, etc.
RenesasRH850 G3K/G3KH/G3M/G3MH/G4MHRH850/C1x, RH850/F1x, RH850/P1x, RH850/E2x, etc.
Intelx86 64-bitIntel 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.
Newsbox Oben
Message from our CEO
Learn what impact COVID19 has on GLIWA. And please let us know if we can help with temporary licenses for example.

Peter Gliwa message

Interviews on YouTube
Check-out the interviews with GLIWA CEO Peter Gliwa on Matrickz TV. In this one Peter talks with MATRICKZ CEO Dr. Hasan Akram about timing in automotive software develeopment and in this one about entrepreneurship.


T1 supports TC39x
Synchronized traces from 6 cores!


Newsbox Unten