1. Home
  2. Embedded Programming
  3. Worst case stack

Worst case stack

I found a nice tool[1] on GitHub.

I run it on one of my embedded projects and after a couple[2] of fixes, it eventually printed some good output.

There were many unresolved functions, mainly from libc, C runtime, interrupts. I defined all of them in .msu, so now in the final output there aren't unresolved functions.

Now there's another big problem. Many functions have an unbounded stack usage and I'm quite sure this depends on function pointers.

For example, I use this[3] printf library. It uses function pointer to emit characters: sprintf calls _vsnprintf() with _out_buffer() function pointer; printf calls _vsnprintf() with _out_char() function pointer.

So sprintf-like functions have an unbounded stack usage, because the poor tool wcs.py isn't able to understand that there are only a few possibilities for the first argument (the function pointer) of _vsnprintf().

It's a pity it isn't possible to set a list of functions for certain functions pointers so wcs.py could print a better result.

[1]
formatting link
[2] The tool emitted some errors on a few WEAK functions that are interrupt handlers. I used .msu file to set a stack usage for those.

Another problem is in print_all_fxns() function and the access to fxn_dict2['demangledName']. For some functions (I think the functions defined in .msu) there weren't 'demangledName' so I print the simple 'name'.

[3]
formatting link
Reply to
pozz
Loading thread data ...

I think MISRA C disallows function pointers, partly for this reason.

Reply to
Paul Rubin

It's not just function pointers (in fact the printf thing should be resolvable), it's recursion, alloca(), variable-sized arrays (a gcc extension), and other things. In general it is not a computable problem.

Reply to
Clifford Heath

Yes, in general there are many obstacles to calculate analitically the worst case stack usage.

Howevere I was talking of *my* project where I don't use recursion, alloca() and so on. I'm quite sure the only problem is with function pointers and it's a pity it's not possible to say those kind of tools which values certain function pointers could have, so it could be able to calc the worst case precisily.

Reply to
pozz

MISRA C contains no such rule, as far as I could see (in MISRA C 2012). It has some rules about what you can do with function pointers, but they are just some of the pointless "you have to write valid C" rules.

Function pointers are a tool that can be very useful for reducing inter-dependency between different modules. But they should be avoided where they are not needed, as they have a lot of disadvantages. They are easy to get wrong, and hard for tools to check automatically. Stack analysis tools are one example here, as are other tools for flow analysis (such as doxygen-generated call graphs) - it's also hard to follow them manually to see when a function might be called if it is used via function pointers. (They can also be less efficient in use, as the compiler knows less about them.)

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.