ttsiodras / checkstackusage

Compute the stack used by each of your functions (via GCC's `-fstack-usage` and call-graph tracing)

(Detailed blog post here )

Introduction

This is a utility that computes the stack usage per function. It is particularly useful in embedded systems programming, where memory is at a premium - and also in safety-critical SW (blowing up from a stack overflow while you operate medical equipment or fly in space is not exactly optimal).

In detail

(Detailed blog post here )

You can read many details about how this script works in the blog post linked above; but the executive summary is this:

• We expect the source code compilation to use GCC's -fstack-usage. This generates .su files with the stack usage of each function (in isolation) stored per compilation unit. Simply put, file.c compiled with -fstack-usage will create file.o and file.su.

• The script can then be launched like so:

  checkStackUsage.py binaryELF folderTreeContainingSUfiles

For example, if after the build we have a tree like this:

bin/
    someBinary
src/
    file1.c
    file1.o
    file1.su
    lib1_src/
            lib1.c
            lib1.o
            lib1.su
    lib2_src/
            lib2.c
            lib2.o
            lib2.su

...we run this:

checkStackUsage.py bin/someBinary src/

The script will scan all .su files in the src folder (recursively, at any depth) and collect the standalone use of stack for each function.

It will then launch the appropriate objdump with option -d - to disassemble the code, and create the call graph. Simplistically, it detects patterns like this:

<foo>:
    ....
    call <func>

...and proceeds from there to create the entire call graph. It can then accumulate the use of all subordinate calls from each function, and therefore compute it's total stack usage.

Output looks like this:

176: foo (foo(16),func(160))
288: func (func(288))
304: bar (bar(16),func(288))
320: main (main(16),bar(16),func(288))

...which means that function foo uses 176 bytes of stack; 16 because of itself, and 160 because it calls func. main uses 320 bytes, etc.

Notice that bar also uses func - but reports a larger stack size for it in that call chain. Read section "Repeated functions" below, to see why; suffice to say, this is one of the few stack checkers that can cope with symbols defined more than once.

Platforms

The script needs to spawn the right objdump. It uses file to detect the ELF signature, and uses appropriate regexes to match disassembly call forms for:

• SPARC/LEONs (used in the European Space Agency missions)
• x86/amd64 (both 32 and 64 bits)
• 32-bit ARM

Adding additional platforms is very easy - just tell the script what objdump flavor to use, and what regex to scan for to locate the call sequences; relevant code is here.

Repeated functions

Each function can only have a specific stack usage - right?

Sadly, no :-(

Feast yourself on moronic - yet perfectly valid - C code like this:

// a.c
static int func() { ...}
void foo() { func(); }

// b.c
static int func() { ...}
void bar() { func(); }

"Houston, we have a problem". While scanning the .su files for a.c and b.c, we find func twice - and due to the static, we want to use the right value on each call (from foo/bar) based on filescope. In effect, the .su files' content need to be read prioritizing local static calls when computing stack usage.

Hidden calls

The scanning of objdump output for call sequences is the best we can do; but it's not perfect. For example, any calls made via function pointer indirections are "invisible" to this process.

And since fp-based calls can do all sorts of shenanigans - e.g. reading the call endpoint from an array of functions via some algorithm - statically deducing which functions are actually called is tantamount to the halting problem.

I am open to suggestions on this.

Static Analysis

The script is written in Python - make all will check it with:

• flake8 (PEP8 compliance)
• pylint (Static Analysis)
• ...and mypy (static type checking).

All dependencies to perform these checks will be automatically installed via pip in a local virtual environment (i.e. under folder .venv) the first time you invoke make all.

Test example

The scenario of repeated functions is tested via make test; in my 64-bit Arch Linux I see this output:

$ make test
...
make[1]: Entering directory '/home/ttsiod/Github/checkStackUsage/tests'
==============================================
       176: foo (foo(16),func(160))
       288: func (func(288))
       304: bar (bar(16),func(288))
       320: main (main(16),bar(16),func(288))
==============================================
1. The output shown above must contain 4 lines
2. 'foo' and 'bar' must both be calling 'func'
   *but with different stack sizes in each*.
3. 'main' must be using the largest 'func'
   (i.e. be going through 'bar')
4. The reported sizes must properly accumulate
==============================================
make[1]: Leaving directory '/home/ttsiod/Github/checkStackUsage/tests'

Given the content of a.c, b.c and main.c, the output looks good. Notice that for func we report the maximum of the two (the one reported by GCC inside b.c, when it is called by bar).

Feedback

If you see something wrong in the script that isn't documented above, questions (and much better, pull requests) are most welcome.

Thanassis Tsiodras, Dr.-Ing. ttsiodras_at-no-spam_thanks-gmail_dot-com

checkstackusage's Issues

Improvement - option checker ParseCmdLIneArgs

Thank you very much for this great and useful tool. I would like to suggest adapting the CMD line parser - see Diff. This has the advantage that the cross-prefix can be specified for all variants.