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] https://github.com/PeterMcKinnis/WorstCaseStack

[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] https://github.com/mpaland/printf

pozz <pozzugno@gmail.com> writes:
> 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.

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

On 18/11/21 3:30 am, pozz wrote:
> 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.

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.

Il 18/11/2021 00:21, Clifford Heath ha scritto:
> On 18/11/21 3:30 am, pozz wrote:
>> 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.
>
> 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.

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.

On 17/11/2021 21:28, Paul Rubin wrote:
> pozz <pozzugno@gmail.com> writes:
>> 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.
>
> I think MISRA C disallows function pointers, partly for this reason.
>

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.)